
http://groups-beta.google.com/group/digitalsource 




Projeto 

de 

Banco de Dados 

CariosA. Heuser* 


© Carlos A. Heuser, 1998 - A publica^ao comercial deste texto esta planejada. Ele deve ser 
considerado como com u nicayao pessoal do autor 




Sumario 


PREFACIO V 

1 INTRODUQAO 1 

1.1 Banco de Dados 2 

1.1.1 Compartilhamento de dados 2 

1.1.2 Sistema de Gerencia de Banco de Dados 4 

1.2 Modelos de Banco de Dados 5 

1 .2. 1 Modelo conceitual 5 

1 .2.2 Modelo logico 6 

1.2.3 Modelo conceitual como modelo de organiza^ao 7 

1.3 Projeto de BD 8 

Exercicios 9 

Referencias Bibliograficas 9 


2 ABORDAGEM ENTIDADE-RELACIONAMENTO 11 

2.1 Entidade 12 

2.2 Relacionamento 13 

2.2.1 Conceitua5ao 13 

2.2.2 Cardinalidade de relacionamentos 15 

2.2.3 Cardinalidade maxima 16 

2.2.4 Classificafao de relacionamentos binarios 17 

2.2.5 Relacionamento ternario 19 

2.2.6 Cardinalidade minima 20 

2.2.7 Exemplo de uso de entidades e relacionamentos 21 

2.3 Atributo 22 

2.3.1 Identificando entidades 24 

2.3.2 Identificando relacionamentos 27 

2.4 General iza^ao/cspccializa^ao 28 

2.5 Entidade associativa 32 

2.6 Esquemas graficos e textuais de modelos ER 34 

Exercicios 37 

Referencias Bibliograficas 40 

3 CONSTRUINDO MODELOS ER 43 

3.1 Propriedades de modelos ER 44 

3.1.1 Um modelo ER e um modelo formal 44 

3.1.2 Abordagem ER tem poder de expressao limitado 44 

3.1.3 Diferentes modelos podem ser equivalentes 46 

3.2 Identificando construfoes 48 

3.2.1 Atributo versus entidade relacionada 48 

3.2.2 Atributo versus gcncralizacao/cspecializacao 49 

3.2.3 Atributos opcionais e multi-valorados 50 



3.3 Verificagao do modelo 53 

3.3.1 Modelo deve ser correto 53 

3.3.2 Modelo deve ser completo 53 

3.3.3 Modelo deve ser livre de redundances 54 

3.3.4 Modelo deve refletir o aspecto temporal 55 

3.3.5 Entidade isolada e entidade sem atributos 59 

3.4 Estabelecendo padroes 59 

3.4.1 Variantes de modelos ER 59 

3.4.2 Uso de ferramentas de modelagem 62 

3.5 Estrategias de modelagem 63 

3.5.1 Partindo de describes de dados existentes 64 

3.5.2 Partindo do conhecimento de pessoas 64 

Exercicios 66 

Referencias Bibliograficas 74 

4 ABORDAGEM RELACIONAL 75 

4.1 Composigao de um Banco de Dados Relacional 76 

4.1.1 Tabelas 76 

4.1.2 Chaves 77 

4.1.3 Domlnios e valores vazios 80 

4.1.4 Restrigoes de integridade 80 

4.2 Especificagao de banco de dados relacional 81 

4.3 Consultas a base de dados 82 

Exercicios 83 

Referencias Bibliograficas 83 

5 TRANSFORMAQOES ENTRE MODELOS 85 

5.1 Visao geral do projeto logico 86 

5.2 Transformagao ER para relacional 87 

5.2.1 Implementagao inicial de entidades 89 

5.2.2 Implementagao de relacionamentos 91 

5.2.3 Detalhes da implementagao de relacionamentos 93 

5.2.4 Implementagao de generalizagao/especiali zagao 100 

5.2.5 Refinamento do modelo relacional 105 

5.3 Engenharia reversa de modelos relacionais 108 

5.3. 1 Identificagac da construgao ER correspondente a cada tabela 110 

5.3.2 Identificagao de relacionamentos 1 :n ou 1 : 1 111 

5.3.3 Definigao de atributos 113 

5.3.4 Definicao de identificadores de entidades 113 



Exercicios 114 

Referencias Bibliograficas 117 

6 ENGENHARIA REVERSA DE ARQUIVOS E NORMALIZAQAO 119 

6.1 Introdufao 120 

6.2 Visao geral do processo de engenharia reversa 120 

6.3 Documento Exemplo 122 

6.4 Representa^ao na forma de tabela nao normalizada 122 

6.5 Normaliza^ao 125 

6.5.1 Passagem a primeira forma normal ( 1FN) 125 

6.5.2 Dependencia funcional 129 

6.5.3 Passagem a segunda forma normal (2FN) 130 

6.5.4 Passagem a terceira forma normal (3FN) 133 

6.5.5 Passagem a quarta forma normal 136 

6.5.6 Problemas da normaliza 5 ao 139 

6.6 Integra^ao de modelos 141 

6.6. 1 Integrafao de tabelas com mesma chave 141 

6.6.2 [ntcgracao de tabelas com chaves contidas 143 

6.6.3 Volta a 2FN 144 

6.7 Construfao do modelo ER e Elimina^ao de Redundances 144 

6.8 Veriflcafao do modelo ER - Li mi taffies da Normaliza^ao 144 

Exercicios 145 

Referencias Bibliograficas 156 

7 SOLUQOES DE EXERCICIOS SELECIONADOS 157 

INDICE REMISSIVO 192 




Prefacio 


Objetivosdo livro 

Sistemas de gerencia de banco de dados (SGBD) surgiram no imcio da decada 
de 70 com o objetivo de facilitar a programagao de aplicagSes de banco de da- 
dos (BD). Os primeiros sistemas eram caros e dificeis de usar, requerendo es- 
pecialistas treinados para usar o SGBD especifico. 

Nessa mesma epoca, houve um investimento consideravel de pesquisa 
na area de banco de dados. Esse investimento resultou em um tipo de SGBD, 
o SGBD relational. A partir da decada de 80 e devido ao barateamento das 
plataformas de hardware /software para executar SGBD relacional, este tipo 
de SGBD passou a dominar o mercado, tendo se convertido em padrao inter- 
nacional. O desenvolvimento de sistemas de informacao ocorre hoje quase 
que exclusivamente sobre banco de dados, com uso de SGBD relacional. 

Alem do SGBD relacional, as pesquisas na area de BD resultaram tam- 
bem em um conjunto de tecnicas, processos e notacoes para o projeto de BD. O 
projeto de BD, que inicialmente era feito com tecnicas empiricas por alguns 
poucos especialistas no SGBD especifico, e executado hoje com auxilio de tec- 
nicas padronizadas e suportadas por ferramentas CASE. Formou-se ao longo 
do tempo um conjunto de conhecimentos sobre projeto de BD que e larga- 
mente aceito e deve ser dominado por qualquer profissional de Informatica. 
Estes conhecimentos sao ministrados nas universidades, ja em cursos de gra- 
duacao, nas disciplinas de fundamentos de banco de dados ou mesmo em dis- 
ciplinas especificas de projeto de banco de dados. 

O projeto de um banco de dados usualmente ocorre em tres etapas. A 
primeira etapa, a modelagem conceitual, procura capturar formalmente os re- 
quisites de informacao de um banco de dados. A segunda etapa, o projeto 16- 
gico, objetiva definir, a nivel de SGBD, as estruturas de dados que implemen- 
tarao os requisitos identificados na modelagem conceitual. A terceira etapa, o 
projeto fisico, define parametros fisicos de acesso ao BD, procurando otimizar a 
performance do sistema como um todo. 

Este livro objetiva ensinar o projeto de banco de dados, cobrindo as duas 
primeiras etapas do ciclo de vida de um banco de dados, a da modelagem 
conceitual e a do projeto logico. 

Na modelagem conceitual, o livro utiliza a abordagem entidade-relaciona- 
mento (ER) de Peter Chen, considerada hoje um padrao "de facto" de modela- 
gem de dados. Alem de apresentar os conceitos e notacoes da abordagem ER, 
o livro apresenta regras e heuristicas para construcao de modelos. 

Com referenda ao projeto logico, o livro cobre tanto o projeto propria- 
mente dito (transformagao de modelos ER em modelos relacionais), quanto a 



engenharia reversa de BD (extracao de modelo conceitual a partir de modelo 16- 
gico relacional ou de arquivos convencionais). 

Publico alvo 

O livro objetiva atender a tres publicos distintos. 

O primeiro e o de alunos de graduagdo de Ciencia da Computagao, de In- 
formatica ou cursos semelhantes. O livro foi concebido para ser usado no en- 
sino de uma primeira abordagem ao tema, o que normalmente ocorre em dis- 
ciplinas de Fundamentos de Banco de Dados ou Projeto de Banco de Dados 
(correspondente a materia obrigatoria T3 do Currlculo de Referenda 96 da 
SBC). O livro se origina de notas de aula que escrevi para suportar parte de 
uma disciplina que ministro ha varios anos no Curso de Bacharelado em Ci- 
encia da Computacao da UFRGS. Para cobrir todo livro necessita-se pelo me- 
nos 20 horas/ aula. Se forem executados alguns dos estudos de caso apresen- 
tados, este tempo deve ser estendido. 

Outro publico e o daqueles profissionais de Informdtica que em sua forma- 
gao nao tiveram contato com os modelos e tecnicas envolvidas no projeto de 
banco de dados. Neste caso, o livro pode ser usado para auto-estudo ou para 
suporte a cursos de extensao ou de especializagao em Projeto de Banco de 
Dados. Mesmo para profissionais que ja conhegam modelagem de dados, o 
livro pode ser util por apresentar um metodo para engenharia reversa de 
banco de dados. Este metodo e importante na atualidade, visto que muitas 
organizagoes contam com sistemas legados e estao envolvidas na tarefa de 
migrar estes sistemas para bancos de dados relacionais. 

Um terceiro publico e o de usudrios de SGBD pessoais, que desejem sis- 
tematizar o projeto de seus bancos de dados. Para este leitores, a parte refe- 
rente a engenharia reversa provavelmente sera demasiado avancada. Entre- 
tanto, o restante do livro e perfeitamente compreensivel para aqueles que tern 
conhecimentos apenas introdutorios de Informatica. 

Onganizaqao 

O livro esta organizado de forma a nao exigir conhecimentos previos na area 
de banco de dados ou de engenharia de software. 

O Capitulo 1 apresenta os conceitos basicos de banco de dados necessa- 
rios a compreensao de restante do texto. Ali sao introduzidos conceitos como 
banco de dados, modelo de dados, sistema de gerencia de banco de dados, 
modelo conceitual e modelo logico. Se o leitor ja dominar estes conceitos, po- 
dera perfeitamente omitir este capitulo. 

O Capitulo 2 esta dedicado a apresentar a abordagem entidade-relacio- 
namento. O objetivo do capitulo e ensinar os conceitos basicos do modelo ER 
e a notacao grafica para apresentacao dos modelos. Como nao ha uma nota- 
gao universalmente aceita para diagramas ER, neste capitulo, preferi usar a 
notacao original de Peter Chen. Sao apresentados tanto os conceitos basicos 
de entidade, atributo e relacionamento, quanto extensoes do ER em diregao a 
modelos semanticos, como o conceito de generalizacao/ especializacao e enti- 
dade associativa. 



Enquanto o Capftulo 2 objetiva a compreensao de modelos entidade- 
relacionamento, o Capftulo 3 objetiva a construgao de modelos ER. Alem de 
apresentar o processo de modelagem, o capftulo inclui uma serie de heurfsti- 
cas a usar na construgao de modelos. Alem disso sao discutidas notacoes al- 
ternativas a de Peter Chen. 

O Capftulo 4 e uma introducao ao modelo relacional. Nao se trata aqui 
de mostrar de forma completa o funcionamento de SGBD relacional, mas 
apenas de transmitir o conhecimento mfnimo necessario para a compreensao 
do restante do livro. Novamente, caso o leitor ja conhega a abordagem relaci- 
onal, podera omitir este capftulo. 

O Capftulo 5 apresenta procedimentos para executar dois tipos de trans- 
formacoes entre modelos de dados. Uma transformacao e o projeto logico de 
banco de dados relacional, ou seja a transformacao de um modelo ER em um 
modelo relacional. A outra transformacao e a engenharia reversa de banco de 
dados relacional, ou seja a transformacao de um modelo logico de banco de da- 
dos relacional em modelo conceitual. 

Finalmente, o Capftulo 6 cobre a engenharia reversa de arquivos, ou seja 
apresenta um conjunto de regras para transformar a descricao de um conjunto 
de arquivos convencionais em um modelo de dados relacional. O conjunto de 
regras esta baseado na normalizacao de banco de dados relacional, que e 
apresentada no capftulo. Por tratar-se de um texto introdutorio, sao 
apresentadas apenas as formas normais da primeira a quarta. 




Capitulo 

1 

Introdugao 


Este capitulo apresenta os conceitos basicos da area de banco de dados que 
sao necessario a compreensao do projeto de banco de dados. Sao apresentados 
conceitos como banco de dados, sistema de gerencia de banco de dados e mo- 
delo de dados. Alem disso e fornecida uma visao geral do projeto de banco de 
dados 

O leitores que ja conhece os fundamentos de banco de dados provavel- 
mente podera passar diretamente ao proximo capitulo. 



1.1 Banco de Dados 

1.1.1 Compartilhamento de dados 

Muitas vezes, a implantacao da Informatica em organizacoes ocorre de forma 
evolutiva e gradual. Inicialmente, apenas determinadas funcoes sao automati- 
zadas. Mais tarde, a medida que o uso da Informatica vai se estabelecendo, 
novas funcoes vao sendo informatizadas. 

Para exemplificar, vamos considerar uma industria hipotetica. Conside- 
ramos que nesta industria sao executadas tres funcoes: 

□ Vendas 

Esta funcao concentra as atividades da industria relativas ao contato com 
os clientes, como fornecimento de cotacoes de precos, vendas, e informa- 
^5es sobre disponibilidade de produtos. 

□ Produgdo 

Esta funcao concentra as atividades da industria relativas a produgao 
propriamente dita, como planejamento da producao e controle do que 
foi produzido. 

□ Compras 

Esta funcao concentra as atividades da industria relativas a aquisicao 
dos insumos necessarios a producao, como cotagSes de pregos junto a 
fornecedores, compras e acompanhamento do fornecimento. 

No exemplo mencionado acima, os dados de um produto sao usados em 
varias funcoes. Estes dados sao necessarios no planejamento de producao, 
pois para planejar o que vai ser produzido, e necessario conhecer como os 
produtos sao estruturados (quais seus componentes) e como sao produzidos. 
Os dados de produto tambem sao necessarios no setor de compras, pois este 
necessita saber que componentes devem ser adquiridos. Ja o setor de vendas 
tambem necessita conhecer dados de produtos, como por exemplo seu prego, 
seu estoque atual, seu prazo de fabricacao, etc. 

Se cada uma das funcoes acima for informatizada de forma separada, 
sem considerar a informatizacao das demais funcoes, pode ocorrer que, para 
cada uma das fun^Ses, seja criado um arquivo separado de produtos (ver 
Figura 1.1). 



Figura 1.1: Sistemas isolados 









Neste caso, surge o problema da redundancia de dados. Redundancia de 
dados ocorre quando uma determinada informacao esta representada no sis- 
tema em computador varias vezes. No caso do exempt o, estao redundantes as 
informacoes referentes a um produto, que aparecem nos arquivos de produ- 
tos de cada um dos tres sistemas. 

Ha duas formas de redundancia de dados, a redundancia controlada de 
dados e a redundancia ndo controlada de dados. 

A redundancia controlada de dados acontece quando o software tern co- 
nhecimento da multipla representacao da informacao e garante a sincronia 
entre as diversas representacoes. Do ponto de vista do usuario externo ao sis- 
tema em computador, tudo acontece como se existisse uma unica representa- 
cao da informacao. Essa forma de redundancia e utilizada para melhorar a 
performance global do sistema. Um exemplo e um sistema distribuido, onde 
uma mesma informacao e armazenada em varios computadores, permitindo 
acesso rapido a partir de qualquer um deles. 

A redundancia ndo controlada de dados acontece quando a responsabili- 
dade pela manutencao da sincronia entre as diversas representacoes de uma 
informacao esta com o usuario e nao com o software. Este tipo de redundan- 
cia deve ser evitado, pois traz consigo varios tipos de problemas: 

□ Redigitagdo 

A mesma informacao e digitada varias vezes. No caso do exemplo da 
industria, os dados de um produto sao digitados no setor de vendas, no 
setor de producao e no setor de compras. Alem de exigir trabalho desne- 
cessario, a redigitagao pode resultar em erros de transcricao de dados. 

□ Inconsistencias de dados 

A responsabilidade por manter a sincronia entre as informacoes e do 
usuario. Por erro de operacao, pode ocorrer que uma representacao de 
uma informacao seja modificada, sem que as demais representacoes o 
sejam. Exemplificando, uma alteracao na estrutura de um determinado 
produto pode ser informada atraves do sistema de producao e deixar de 
ser informada nos demais sistemas. A estrutura do produto passa a apa- 
recer de forma diferente nos varios sistemas. O banco de dados passa a 
ter informacoes inconsistentes. 

A solucao para evitar a redundancia nao controlada de informacoes e o 
compartilhamento de dados. Nesta forma de processamento, cada informacao e 
armazenada uma unica vez, sendo acessada pelos varios sistemas que dela 
necessitam (Figura 1.2). Ao conjunto de arquivos integrados que atendem a 
um conjunto de sistemas da-se o nome de banco de dados (BD). 

banco de dados 

conjunto de dados integrados que tern por 
objetivo atender a uma comunidade de 
usuarios 





Figura 1.2: Sistemas integrados com dados compartilhados 

O compartilhamento de dados tem reflexos na estrutura do software. A 
estrutura interna dos arquivos passa a ser mais complexa, pois estes devem 
ser construtdos de forma a atender as necessidades dos diferentes sistemas. 
Para contornar este problema, usa-se um sistema de gerencia de banco de dados, 
conforme descrito na proxima secao. 

1.1.2 Sistema de Gerencia de Banco de Dados 

A programacao de aplicagSes em computadores sofreu profundas modifica- 
qoes desde seus primordios. No inicio, quando usavam-se linguagens como 
COBOL, Basic, C e outras, os programadores incorporavam em um programa 
toda funcionalidade desejada. O programa continha as operacoes da interface 
de usuario, as transformagSes de dados e calculos, as operates de armaze- 
namento de dados, bem como as tarefas de comunicacao com outras sistemas 
e programas. 

Com o tempo, foram sendo identificadas funcionalidades comuns a 
muitos programas. Por exemplo, hoje em dia, a grande maioria dos progra- 
mas comunica-se com os usuarios atraves de interfaces graficas de janelas. 
Entretanto, normalmente, os programas nao contem todo codigo referente a 
exibicao dos dados na interface, mas utilizam gerenciadores de interface de usud- 
rio, conjuntos de rotinas que incluem as funcionalidades que um programador 
vai necessitar frequentemente, ao construir uma interface de usuario. Da 
mesma forma, para comunicar-se com processos remotos, usam gerenciadores 
de comunicagdo. Para manter grandes repositories compartilhados de dados, 
ou seja, para manter bancos de dados, sao usados sistemas de gerencia de banco de 
dados (SGBD). 

sistema de gerencia de banco de dados 

software que incorpora as fungSes de 
definigao, recuperagao e alteragao de dados 
em um banco de dados 


Essa modularizacao de programas tem varias vantagens. A manutengdo 
de programas torna-se mais simples, pois uma separagao clara de funcoes 
torna programas mais facilmente compreensiveis. A produtividade de progra- 








madores tambem aumenta, ja que os programas ficam menores, pois usam 
funcoes ja construidas. 

No mercado, ha varios tipos de SGBD. Neste livro, nos concentramos em 
um tipo de SGBD, o relational, que domina o mercado da atualidade. Entre- 
tanto, muitas das ideias apresentadas nas secoes referentes a modelagem de 
dados aplicam-se tambem a outros tipos, como os SGBD orientados a objetos 
ou objeto/relacionais. 

1 .2 Modelos de Banco de Dados 

Um modelo de (banco de) dados e uma descricao dos tipos de informacoes que 
estao armazenadas em um banco de dados. Por exemplo, no caso da industria 
citado acima, o modelo de dados poderia informar que o banco de dados ar- 
mazena informacoes sobre produtos e que, para cada produto, sao armazena- 
dos seu codigo, prego e descricao. Observe que o modelo de dados nao in- 
forma quais os produtos que estao armazenados no banco de dados, mas 
apenas que o banco de dados content informacoes sobre produtos. 

modelo de dados 

descricao formal da estrutura de um banco 
de dados 


Para construir um modelo de dados, usa-se uma linguagem de modelagem 
de dados. Linguagens de modelagem de dados podem ser classificadas de 
acordo com a forma de apresentar modelos, em linguagens textuais ou lingua- 
gens grdficas. Como veremos adiante, um mesmo modelo de dados pode ser 
apresentado de varias formas. Cada apresentacao do modelo recebe a deno- 
minacao esquema de banco de dados. 

De acordo com a intengao do modelador, um banco de dados pode ser 
modelado (descrito) ha varios niveis de abstragao. Um modelo de dados que 
servira para explicar a um usuario qual e a organizacao de um banco de da- 
dos provavelmente nao contera detalhes sobre a representagao em meio fisico 
das informagSes. Ja um modelo de dados usado por um tecnico para otimizar 
a performance de acesso ao banco de dados contera mais detalhes de como as 
informacoes estao organizadas internamente e portanto sera menos abstrato. 

No projeto de banco de dados, normalmente sao considerados dois m- 
veis de abstragao de modelo de dados, o do modelo conceitnal e o do modelo 16 - 
gico. 

1.2.1 Modelo conceitual 

Um modelo conceitnal e uma descricao do banco de dados de forma indepen- 
dente de implementacao em um SGBD. O modelo conceitual registra que da- 
dos podem aparecer no banco de dados, mas nao registra como estes dados 
estao armazenados a nivel de SGBD. 




modelo conceitual 

modelo de dados abstrato, que descreve a 
estrutura de um banco de dados de forma 
independente de um SGBD particular 


A tecnica mais difundida de modelagem conceitual e a abordagem enti- 
dade-relacionamento (ER). Nesta tecnica, um modelo conceitual e usualmente 
representado atraves de um diagrama, chamado diagrama entidade-relaciona- 
mento (DER). A Figura 1.3 apresenta um DER parcial para o problema da fa- 
brica. 



Figura 1.3: Exemplo de modelo conceitual 

Entre outras coisas, este modelo informa que o banco de dados contem 
dados sobre produtos e sobre tipos de produtos. Para cada produto, o banco 
de dados armazena o codigo, a descrigao, o prego, bem como o tipo de pro- 
duto ao qual esta associado. Para cada tipo de produto, o banco de dados ar- 
mazena o codigo, a descrigao, bem como os produtos daquele tipo. 

1.2.2 Modelo logico 

Um modelo logico e uma descrigao de um banco de dados no nivel de abstragao 
visto pelo usuario do SGBD. Assim, o modelo logico e dependente do tipo 
particular de SGBD que esta sendo usado. 

No presente livro, serao tratados apenas modelos logicos referentes a 
SGBD relacional. Em um SGBD relacional, os dados estao organizados na 
forma de tabelas. 

A Figura 1.4 mostra um exemplo de BD relacional projetado a partir do 
modelo conceitual mostrado na Figura 1.3. Um modelo logico para o BD 
acima deve definir quais as tabelas que o banco contem e, para cada tabela, 
quais os nomes das colunas. 

Abaixo e apresentado o modelo logico (de forma textual) da Figura 1.4: 
TipoDeProdutol CodTipoProd , DescrTipoProd) 
Produto( CodProd ,DescrProd.PrecoProd,CodTipoProd) 

CodTipoProd referenda TipoDeProduto 



TipoDeProduto 


CodTipoProd 

DescrTipoProd 

1 

Computador 

2 

Impressora 


Produto 


Cod Prod 

DescrProd 

PrecoProd 

CodTipoProd 

1 

PC desktop modelo X 

2.500 

1 

2 

PC notebook ABC 

3.500 

1 

3 

Impressora jato de tinta 

600 

2 

4 

Impressora laser 

800 

2 


Figura 1.4: Exemplo de tabelas de BD relacional 

O modelo logico descreve a estrutura do banco de dados, conforme vista 
pelo usuario do SGBD. Detalhes de armazenamento interno de informacoes, 
que nao tem influencia sobre a programacao de aplicacoes no SGBD, mas po- 
dem influenciar a performance da aplicacoes (por exemplo, as estruturas de 
arquivos usadas no acesso as informagSes) nao fazem parte do modelo logico. 
Estas sao representadas no modelo fisico. Modelos fisicos nao sao tratados neste 
livro. Eles sao usados apenas por profissionais que fazem sintonia de banco de 
dados, procurando otimizar a performance. As linguagens e notacoes para o 
modelo fisico nao sao padronizadas e variam de produto a produto. A ten- 
dencia em produtos mais modernos e esconder o modelo fisico do usuario e 
transferir a tarefa de otimizacao ao proprio SGBD. 

modelo logico 

modelo de dados que representa a estrutura 
de dados de um banco de dados conforme 
vista pelo usuario do SGBD 


1.2.3 Modelo conceitual como modelo de organiza^ao 

Quando se observa um conjunto de arquivos em computador, sejam eles ge- 
renciados por um SGBD, sejam eles arquivos convencionais, verifica-se que 
usualmente um arquivo contem informacoes sobre um conjunto de objetos ou 
entidades da organizacao que e atendida pelo sistema em computador. Assim, 
no exemplo da industria acima citado, um sistema em computador provavel- 
mente conteria um arquivo para armazenar dados de produtos, outro para 
armazenar dados de vendas, outro para armazenar dados de ordens de com- 
pra e assim por diante. 

Desta constatacao surgiu uma das ideias fundamentals do projeto de 
banco de dados: a de que atraves da identificagao das entidades que terao in- 
formacoes representadas no banco de dados, e possivel identificar os arquivos 
que comporao o banco de dados. Devido a esta relacao um-para-um entre ar- 






quivos em computador e entidades da organizacao modelada, observou-se 
que um mesmo modelo conceitual pode ser usado em duas fun^Ses: 

□ como modelo abstrato da organizagao, que define as entidades da organizacao 
que tem informacoes armazenadas no banco de dados, e 

□ como modelo abstrato do banco de dados, que define que arquivos farao parte 
do banco de dados. 

Exemplificando, se considerarmos o modelo da Figura 1.3 podemos in- 
terpreta-lo de duas formas. Em uma interpretacao, como modelo abstrato da 
organizacao, o diagrama nos informa que na organizacao ha produtos e tipos 
de produtos, que associado a cada tipo de produto ha um codigo do tipo e 
uma descricao e assim por diante. Na outra interpretacao, como modelo abs- 
trato de um banco de dados, o diagrama nos informa que o banco de dados 
devera confer informacoes sobre produtos e tipos de produtos, que para cada 
tipo de produto sao armazenados seus codigo e sua descricao e assim por di- 
ante. 

Na pratica, convencionou-se iniciar o processo de construcao de um 
novo banco de dados com a construcao de um modelo dos objetos da organi- 
zacao que sera atendida pelo banco de dados, ao inves de partir diretamente 
para o projeto do banco de dados. 

Esta forma de proceder permite envolver o usuario na especificacao do 
banco de dados. Sabe-se da pratica da engenharia de software que o envolvi- 
mento do usuario na especificacao do software aumenta a qualidade do 
software produzido. A ideia e que o usuario e aquele que melhor conhece a 
organizacao e, portanto, aquele que melhor conhece os requisitos que o 
software deve preencher. Modelos conceituais sao modelos que descrevem a 
organizacao e portanto sao mais simples de compreender por usuarios leigos 
em Informatica, que modelos que envolvem detalhes de implementacao. 

1.3 Projeto deBD 

O projeto de um novo BD da-se em duas fases: 

1 Modelagem conceitual 

Nesta primeira fase, e construido um modelo conceitual, na forma de 
um diagrama entidade-relacionamento. Este modelo captura as necessi- 
dades da organizacao em termos de armazenamento de dados de forma 
independente de implementacao. 

2 Projeto logico 

A etapa de projeto logico objetiva transformar o modelo conceitual ob- 
tido na primeira fase em um modelo logico. O modelo logico define 
como o banco de dados sera implementado em um SGBD especifico. 

O processo acima e adequado para a construcao de um novo banco de 
dados. Caso ja exista um banco de dados ou um conjunto de arquivos con- 
vencionais, e se pretenda construir um novo banco de dados, o processo 
acima e modificado e incorpora uma etapa de engenharia reversa de banco de 
dados. A engenharia reversa e explicada nos capitulos 5 e 6. 



Exercicios 


Exercicio 1.1: Enumere as principals diferencas entre o processamento de da- 
dos com arquivos convencionais e o processamento de dados com SGBD. 
Exercicio 1.2: Descreva alguns fatores que levam alguem a preferir o uso de 
arquivos convencionais ao uso de SGBD. Descreva alguns fatores que levam 
alguem a preferir o uso de SGBD ao uso de arquivos convencionais. 

Exercicio 1.3: Defina, sem retornar ao capitulo acima, os seguintes conceitos: 
banco de dados, sistema de gerencia de banco de dados, modelo de dados, 
modelo conceitual, modelo logico, modelagem conceitual e projeto logico. Ve- 
rifique a definicao que voce fez contra a apresentada no capitulo. 

Exercicio 1.4: A definicao do fa tor de bloco de um arquivo faz parte de que 
modelo: do modelo conceitual, do modelo logico ou do modelo fisico? 
Exercicio 1.5: A definicao do tipo de um dado (numerico, alfanumerico,...) faz 
parte de que modelo: do modelo conceitual, do modelo logico ou do modelo 
fisico? 

Exercicio 1.6: Qual a diferenga entre a redundancia de dados controlada e a 
redundancia de dados nao controlada? De exemplos de cada uma delas. 

References Bbuograrcas 
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Silberschatz [2] e de Elmasri e Navathe [1], este ultimo sem tradugao para 
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Edition. Benjamin /Cummings, Redwood City, California, 1994 

[2] Korth, H. & Silberschatz, A. Sistemas de Buncos de Dados. 2 a edicao, 
Makron Books, 1994 




Capitulo 

2 

Abordagem 

Entidade 

Relacionamento 


Como vimos no Capitulo 1, a primeira etapa do projeto de um banco de da- 
dos e a construcao de um modelo conceitual, a chamada modelagem conceitual. 
O objetivo da modelagem conceitual e obter uma descricao abstrata, indepen- 
dente de implementacao em computador, dos dados que serao armazenados 
no banco de dados. 

A tecnica de modelagem de dados mais difundida e utilizada e a aborda- 
gem entidade-relacionamento (ER). Nesta tecnica, o modelo de dados e repre- 
sentado atraves de um modelo entidade-relacionamento (modelo ER). Usualmente, 
um modelo ER e representado graficamente, atraves de um diagrama entidade- 
relacionamento (DER). A abordagem ER foi criada em 1976 por Peter Chen. Ela 
pode ser considerada como um padrao de fato para modelagem conceitual. 
Mesmo as tecnicas de modelagem orientada a objetos que tern surgido nos 
ultimos anos baseiam-se nos conceitos da abordagem ER. 

Este capitulo tern por objetivo apresentar os conceitos centrais da abor- 
dagem ER: entidade, relacionamento, atributo, generalizagdo/especializagdo e enti- 
dade associativa. Junto com os conceitos, e apresentada uma notacao grafica 
para diagramas ER. A notacao grafica usada no capitulo e a notacao original- 
mente introduzida por Peter Chen. No Capitulo 3, sao discutidas outras nota- 
qoes para representar diagramas ER. 



2.1 Entidade 

O conceito fundamental da abordagem ER e o conceito de entidade. 

entidade 

conjunto de objetos 1 da realidade modelada 
sobre os quais deseja-se manter informagSes 
no banco de dados 

Uma entidade representa, no modelo conceitual, um conjunto de objetos 
da realidade modelada. Como o objetivo de um modelo ER e modelar de 
forma abstrata um BD, interessam-nos somente os objetos sobre os quais de- 
seja-se manter informagSes. Vejamos alguns exemplos. No sistema de infor- 
magSes industrial que usamos no Capitulo 1, alguns exemplos de entidades 
poderiam ser os produtos, os tipos de produtos, as vendas ou as compras. Ja 
em um sistema de contas correntes, algumas entidades podem ser os clientes, 
as contas correntes, os cheques e as agendas. Observe que uma entidade pode 
representar tanto objetos concretos da realidade (uma pessoa, um automovel), 
quanto objetos abstratos (um departamento, um endereco 2 ). 

Em um DER, uma entidade e representada atraves de um retangulo que 
content o nome da entidade. Alguns exemplos sao mostrados na Figura 2.1. 


PESSOA 


DEPARTAMENTO 


Figura 2.1: Representagao grafica de entidades 

Como dito acima, cada retangulo representa um conjunto de objetos so- 
bre os quais deseja-se guardar informacoes. Assim, no exemplo, o primeiro 
retangulo designa o conjunto de todas pessoas sobre as quais se deseja manter 
informacoes no banco de dados, enquanto o segundo retangulo designa o 
conjunto de todos departamentos sobre os quais se deseja manter informa- 
qoes. Caso seja necessario referir um objeto particular (uma determinada pes- 
soa ou um determinado departamento) fala-se em ocorrencia de entidade (al- 
guns autores usam tambem o anglicismo ‘‘instdncia’' de entidade). 

Ela autores que preferem usar o par de termos conjunto de entidades e en- 
tidade para designar respectivamente o conjunto de objetos e cada objeto in- 
dividual. Essa terminologia e a primeira vista mais adequada pois corres- 
ponde ao uso dos termos na linguagem natural, onde "entidade" e um indi- 
viduo e nao um coletivo. Entretanto, esta terminologia nao e adequada no 


1 O termo "objeto" possui aqui a conotacao que e lhe dada na linguagem natural, de 
"coisa, tudo que e percepttvel ou manipulavel". Nao estamos falando aqui do termo "objeto" 
como usado na modelagem e na programacao orientadas a objetos, onde o termo tern uma 
conotacao mais precisa. 

2 Neste ponto, aquele que ja possui conhecimento sobre a modelagem ER podera estar 
pensando: "Obviamente endereco e um atributo e nao uma entidade!". Se voce e um desses 
leitores, peco um pouco de paciencia, pois esta questao sera esclarecida mais adiante. 




projeto de BD, no qual falamos com grande frequencia sobre conjuntos de 
objetos e raramente sobre individuos. Por esse motivo preferimos usar o par 
de termos entidade e ocorrencia de entidade. 

2.2 Relacionamento 
2.2.1 Conceituagao 

Alem de especificar os objetos sobre os quais deseja-se manter informa- 
tes, o DER deve permitir a especificagao das propriedades dos objetos que 
serao armazenadas no BD. Uma das propriedades sobre as quais pode ser de- 
sejavel manter informates e a associate* entre objetos. Exemplificando, pode 
ser desejavel saber quais pessoas estao associadas a quais departamentos em 
uma organizagao. 

relacionamento 

conjunto de associates entre entidades 

Em um DER, um relacionamento e representado atraves de um losango, 
ligado por linhas aos retangulos representatives das entidades que participam 
do relacionamento. A Figura 2.2 apresenta um DER contendo duas entidades, 
PESSOA e DEPARTAMENTO, e um relacionamento, LOTAQAO. 



Figura 2.2: Representagao grafica de relacionamento 

Este modelo expressa que o BD mantem informates sobre: 

□ um conjunto de objetos classificados como pessoas (relacionamento 
PESSOA) 

□ um conjunto de objetos classificados como departamentos (relaciona- 
mento DEPARTAMENTO) 

□ um conjuntos de associates, que ligam um departamento a uma pessoa. 
(relacionamento LOTAQAO). 

Da mesma forma que fizemos com entidades, quando quisermos nos re- 
ferir a associates particulares dentro de um conjunto, vamos nos referir a 
ocorrencias de relacionamentos. No caso do relacionamento LOTAQAO uma 
ocorrencia seria um par especifico formado por uma determinada ocorrencia 
da entidade PESSOA e por uma determinada ocorrencia da entidade 
DEPARTAMENTO. 

Para fins didaticos, pode ser util construir um diagrama de ocorrencias, 
como o apresentado na Figura 2.3. Este diagrama refere-se ao modelo ER da 
Figura 2.2. Em um diagrama de ocorrencias, ocorrencias de entidades sao re- 
presentadas por circulos brancos e ocorrencias de relacionamentos por circu- 
los negros. As ocorrencias de entidades participantes de uma ocorrencia de 
relacionamento sao indicadas pelas linhas que ligam o circulo negro repre- 



sentativo da ocorrencia de relacionamento aos cfrculos brancos representati- 
ves das ocorrencias de entidades relacionadas. Assim, a Figura 2.3 representa 
que ha uma ocorrencia de LOTAQAO que liga a pessoa pi com o departa- 
mento dl. Observe-se que, na forma como esta, o modelo da Figura 2.2 nao 
informa quantas vezes uma entidade e associada atraves de um relaciona- 
mento (veremos como isso pode ser representado mais abaixo). O modelo 
apresentado permite que uma ocorrencia de entidade (por exemplo, a pessoa 
p3) nao esteja associada a nenhuma ocorrencia de entidade atraves do relaci- 
onamento, ou uma ocorrencia de entidade (por exemplo, a pessoa pi) esteja 
associada a exatamente uma ocorrencia de entidade atraves do relaciona- 
mento, ou ainda, que uma ocorrencia de entidade (por exemplo, o departa- 
mento dl) esteja associada a mais de uma ocorrencia de entidade atraves do 
relacionamento. 



entidade 

EMPREGADO 


relacionamento 

LOTAQAO 


entidade 

DEPARTAMENTO 


Figura 2.3: Diagrama de ocorrencias 

Nao necessariamente um relacionamento associa entidades diferentes. A 
Figura 2.4 mostra um DER que contem um auto-relacionamento, isto e, um rela- 
cionamento entre ocorrencias de uma mesma entidade. Neste caso, e necessa- 
rio um conceito adicional, o de papel da entidade no relacionamento. No caso 
do relacionamento de casamento, uma ocorrencia de pessoa exerce o papel de 
marido e a outra ocorrencia de pessoa exerce o papel de esposa. Papeis sao 
anotados no DER como mostrado na Figura 2.4. No caso de relacionamentos 
entre entidades diferentes, como o de LOTAQAO mostrado acima, nao e ne- 
cessario indicar os papeis das entidades, ja que eles sao obvios. 


mar\do 



Figura 2.4: Auto-relacionament 

A Figura 2.5 apresenta um possivel diagrama de ocorrencias para o DER 
da Figura 2.4. Os papeis (marido e esposa) das ocorrencias de entidades em 
cada ocorrencia de relacionamento foram anotadas nas linhas que ligam os 
circulos representatives das ocorrencias de entidades e relacionamentos. 



Figura 2.5: Diagrama de ocorrencias para o relacionamento casamento 

2.2.2 Cardinalidade de relacionamentos 

Para fins de projeto de banco de dados, uma propriedade importante de um 
relacionamento e a de quantas ocorrencias de uma entidade podem estar as- 
sociadas a uma determinada ocorrencia atraves do relacionamento. Esta pro- 
priedade e chamada de cardinalidade de uma entidade em um relacionamento. 
Fla duas cardinalidades a considerar: a cardinalidade maxima e a cardinali- 
dade minima. 

cardinalidade (minima, maxima) de entidade 
em relacionamento 

numero (minimo, maximo) de ocorrencias 
de entidade associadas a uma ocorrencia da 
entidade em questao atraves do 
relacionamento 




2.2.3 Cardinalidade maxima 

Para exemplificar o conceito de cardinalidade vamos retomar o exemplo da 
Figura 2.2. Vamos considerar as seguintes cardinalidade maximas: 

□ Entidade EMPREGADO tem cardinalidade maxima 1 no relacionamento 
LOTAQAO: 

Isso significa que uma ocorrencia de EMPREGADO pode estar associada a 
no maximo uma ocorrencia de DEPARTAMENTO, ou em outros termos, 
que um empregado pode estar lotado em no maximo um departamento 

□ Entidade DEPARTAMENTO tem cardinalidade maxima 120 no relaciona- 
mento LOTAQAO: 

Isso significa que uma ocorrencia de DEPARTAMENTO pode estar associ- 
ada a no maximo 120 ocorrencias de EMPREGADO, ou em outros termos, 
que um departamento pode ter nele lotado no maximo 120 empregados. 
Para fins praticos, nao e necessario distinguir entre diferentes cardinali- 
dades maximas maiores que 1. Por este motivo, apenas duas cardinalidades 
maximas sao relevantes: a cardinalidade maxima lea cardinalidade maxima 
"muitos", referida pela letra n. Assim, no exemplo acima, diz-se que a cardi- 
nalidade maxima da entidade DEPARTAMENTO no relacionamento 
LOTAQAO e n. 

A cardinalidade maxima e representada no DER conforme indicado na 
Figura 2.6. Observe a convencao usada. A primeira vista, ela pode parecer 
pouco natural, ja que vai anotada "do outro lado" do relacionamento a qual se 
refere. Exemplificando, a cardinalidade maxima da entidade EMPREGADO 
no relacionamento LOTAQAO e anotada junto ao simbolo da entidade 
DEPARTAMENTO. 



expressa que a uma ocorrencia de EMPREGADO 
(entidade do lado oposto da anotacao) pode estar associada 
ao maximo uma (“1”) ocorrencia de DEPARTAMENTO 


expressa que a uma ocorrencia de DEPARTAMENTO 
(entidade ao lado oposto da anotacao) podem estar associadas 



Figura 2.6: Cardinalidade maxima de relacionamento 


2.2.4 Classifica^ao de relacionamentos binarios 

A cardinalidade maxima pode ser usada para classificar relacionamentos bi- 
narios. Um relacionamento binario e aquele cujas ocorrencias envolvem duas 
entidades, como todos vistos ate aqui. Podemos classificar os relacionamentos 
em n:n (muitos-para-muitos), l:n (um-para-muitos) e 1:1 (um-para-um). A 
Figura 2.7, a Figura 2.8 e a Figura 2.9 apresentam exemplos de relacionamen- 
tos com cardinalidades maximas 1:1, l:n e n:n, respectivamente. A seguir co- 
mentamos a interpretagao de alguns relacionamentos apresentados nestas fi- 
guras. 

Na Figura 2.7, no relacionamento CASAMENTO, as cardinalidades ma- 
ximas expressam que uma pessoa pode possuir no maximo um marido (uma 
instancia de pessoa pode estar associada via relacionamento a no maximo 
outra pessoa no papel de esposa) e no maximo uma esposa. 

Observe que este relacionamento, apesar de envolver apenas uma enti- 
dade, e tambem considerado como um relacionamento binario. O que deter- 
mina o fato de o relacionamento ser binario e o numero de ocorrencias de en- 
tidade que participam de cada ocorrencia do relacionamento. De cada ocor- 
rencia de CASAMENTO participam exatamente duas ocorrencias da entidade 
PESSOA (um marido e uma esposa). Por este motivo, o relacionamento de 
CASAMENTO e classificado como sendo binario. 

A Figura 2.8 mostra outros exemplos de relacionamentos l:n, alem do 
relacionamento LOTAQAO que ja ha via sido visto acima. O relacionamento 
INSCRIQAO modela a inscrigao de alunos em uma universidade publica, 
onde existe a restricao de que um aluno pode estar inscrito em no maximo um 
curso. 



Figura 2.7: Relacionamentos 1:1 

O relacionamento INSCRIQAO da Figura 2.8 representa a associagao 
entre cursos de uma Universidade publica e seus alunos. Por tratar-se de uma 
universidade publica, cada aluno pode estar vinculado a um curso no ma- 
ximo. 



Figura 2.8: Relacionamentos l:n 



Figura 2.9: Relacionamentos n:n 

O relacionamento entre as entidades EMPREGADO e DEPEN DENTE 
(Figura 2.8) modela a associagao entre um empregado e seus dependentes 
para fins de imposto de renda. Neste caso, um dependente pode estar associ- 
ado a no maximo um empregado. Cabe observar que no DER, nao foi anotado 
o nome do relacionamento. No caso de no DER nao constar o nome do relaci- 


onamento, este e denominado pela concatenacao de nomes das entidades 
participantes. Assim, neste caso, o relacionamento e denominado 
EMPREGADO-DEPENDENTE. 

O relacionamento SUPERVISAO (Figura 2.8) e um exemplo de auto- 
relacionamento l:n. Ele modela a associagao entre um empregado 
(supervisor) e seus supervisionados imediatos. A cardinalidade maxima 
expressa que um empregado pode possuir no maximo um supervisor, mas 
muitos supervisionados. 

O tipo menos restrito de relacionamento e o de cardinalidade n:n. A 
Figura 2.9 apresenta alguns relacionamentos deste tipo, inclusive o de um 
auto-relacionamento. 

2.2.5 Relacionamento ternario 

Todos exemplos ate aqui mostrados sao de relacionamentos binarios, ou seja, 
de relacionamentos que associam exatamente duas entidades. A abordagem 
ER permite que sejam definidos relacionamentos de grau maior do que dois 
(relacionamentos temarios, quatemarios,...). O DER da Figura 2.10 mostra um 
exemplo de um relacionamento ternario. 

Cada ocorrencia do relacionamento DISTRIBUIQAO associa tres ocor- 
rencias de entidade: um produto a ser distribuido, uma cidade na qual e feita 
a distribuigao e um distribuidor. 

No caso de relacionamentos de grau maior que dois, o conceito de car- 
dinalidade de relacionamento e uma extensao nao trivial do conceito de car- 
dinalidade em relacionamentos binarios. Lembre-se que, em um relaciona- 
mento binario R entre duas entidades A e B, a cardinalidade maxima de A em 
R indica quantas ocorrencias de B podem estar associadas a cada ocorrencia 
de A. No caso de um relacionamento ternario, a cardinalidade refere-se a 
pares de entidades. Em um relacionamento R entre tres entidades A, B e C, a 
cardinalidade maxima de A e B dentro de R indica quantas ocorrencias de C 
podem estar associadas a um par de ocorrencias de A e B. 



Figura 2.10: Relacionamento ternario 



Figura 2.1 1 : Cardinalidade em relacionamentos ternarios 

Exemplificando, na Figura 2.11, o “1” na linha que liga o retangulo 
representativo da entidade DISTRIBUIDOR ao losango representativo do 
relacionamento expressa que cada par de ocorrencias (cidade, produto) esta 
associado a no maximo um distribuidor. Em outros termos, nao ha 
concorrencia pela distribui^ao de um produto em uma cidade. 

Ja os dois “n" expressam que: 

□ A um par (cidade, distribuidor) podem estar associados muitos 
produtos, ou em outros termos, um distribuidor pode distribuir em uma 
cidade muitos produtos. 

□ A um par (produto, distribuidor) podem estar associadas muitas 
cidades, ou em outros termos um distribuidor pode distribuir um 
produto em muitas cidades. 

2.2.6 Cardinalidade minima 

Alem da cardinalidade maxima, uma outra inform a qao que pode ser 
representada por um modelo ER e o numero minimo de ocorrencias de 
entidade que sao associadas a uma ocorrencia de uma entidade atraves de um 
relacionamento. Para fins de projeto de BD, consideram-se apenas duas 
cardinalidades minimas: a cardinalidade minima 0 e a cardinalidade 
minima 1. 

A cardinalidade minima 1 tambem recebe a denominagao de "associagao 
obrigatoria ” , ja que ela indica que o relacionamento deve obrigatoriamente 
associar uma ocorrencia de entidade a cada ocorrencia da entidade em 
questao. Com base na mesma linha de raciocinio, a cardinalidade minima 0 
tambem recebe a denominacao de "associagao optional” . 

A cardinalidade minima e anotada no diagrama junto a cardinalidade 
maxima, conforme mostrado na Figura 2.12. Nesta figura, aparece novamente 
o exemplo da alocagao de empregados a mesas que ja foi apresentado 
anteriormente. Aqui, a cardinalidade minima e usada para especificar que 
cada empregado deve ter a ele alocada obrigatoriamente uma mesa 


(cardinalidade minima 1) e que uma mesa pode existir sem que a ela esteja 
alocado um empregado (cardinalidade minima 0). 



Figura 2.12: Cardinalidade minima de relacionamento 

2.2.7 Exemplo de uso de entidades e relacionamentos 

A Figura 2.13 apresenta um exemplo de um diagrama entidade- 
relacionamento mais abrangente que os anteriores, envolvendo diversas 
entidades e relacionamentos. Como se ve, um diagrama ER e apresentado na 
forma de um grafo. A distribuicao dos simbolos de DER no papel e totalmente 
arbitraria e nao tern maior significado do ponto de vista formal. Entretanto, 
para tornar o diagrama mais legivel e usual evitar-se cruzamentos de linhas. 
Para isso, a recomendagao geral e a de posicionar os retangulos 
representatives de entidades que participam de muitos relacionamentos no 
centro do diagrama. 



Figura 2.13: DER para o controle academico de uma universidade 









O modelo da Figura 2.13 e uma parte do modelo de dados de um 
sistema de controle academico de uma universidade ficticia. O modelo 
descreve o seguinte: 

□ Deseja-se manter informacoes sobre alunos, cursos, disciplinas e 
departamentos. 

□ Alem disso, deseja-se manter informacoes sobre a associagao de alunos a 
cursos, de disciplinas a cursos, de disciplinas a departamentos, bem como 
de disciplinas a suas disciplinas pre-requisitos. 

□ Atraves das cardinalidades expressa-se que: 

> Cada disciplina possui exatamente um departamento responsavel, e 
um departamento e responsavel por muitas disciplinas, inclusive por 
nenhuma. Note-se que, apesar de sabermos que os departamentos em 
uma universidade existem para ser responsaveis por disciplinas, 
especificamos a cardinalidade minima de DEPARTAMENTO em 
RESPONSAVEL como sendo "0". Com isso admitimos a possibilidade 
de existirem departamentos vazios. Esta cardinalidade foi especificada 
considerando o estado do banco de dados imediatamente apos a 
criacao de um novo departamento, bem como o estado imediatamente 
antes da eliminacao de um departamento. Da forma como a restricao 
foi especificada, e possivel incluir o departamento em uma transacao, 
para, depois, em transacoes subsequentes, vincula-lo as disciplinas sob 
sua responsabilidade. Se tivesse sido especificada a cardinalidade 
minima "1 " , ao menos uma disciplina teria que ser vinculada ao 
departamento ja na propria transacao de inclusao do departamento. 
Como observa-se da discussao acima, para especificar as 
cardinalidades minimas e necessario possuir conhecimento sobre as 
transacoes de inclusao e exclusao das entidades. 

> Uma disciplina pode possuir diversos pre-requisitos, inclusive 
nenhum. Uma disciplina pode ser pre-requisito de muitas outras 
disciplinas, inclusive de nenhuma. 

> Uma disciplina pode aparecer no curriculo de muitos cursos (inclusive 
de nenhum) e um curso pode possuir muitas disciplinas em seu 
curriculo (inclusive nenhuma). 

> Um aluno esta inscrito em exatamente um curso e um curso pode ter 
nele inscritos muitos alunos (inclusive nenhum). 

2.3 Atributo 

Para associar informacoes a ocorrencias de entidades ou de relacionamentos 
usa-se o conceito de atributo. 



atributo 

dado que e associado a cada ocorrencia de 
uma entidade ou de um relacionamento 


PROJETO 

i ti po 
O codigo 
O nome 

Figura 2.14: Atributos de uma entidade 

Atributos sao representados graficamente conforme mostra a Figura 
2.14. A figura expressa que a cada ocorrencia de PROJETO e associado exa- 
tamente um nome, um codigo e um tipo. 

Na pratica, atributos nao sao representados graficamente, para nao 
sobrecarregar os diagramas, ja que muitas vezes entidades possuem um 
grande numero de atributos. Prefere-se usar uma representagao textual que 
aparece separadamente do diagrama ER. Ao final deste capitulo, e fornecida 
uma possivel sintaxe para uma representagao textual dos atributos. No caso 
de ser usado um software para construgao de modelos ER, o proprio software 
encarrega-se do armazenamento da lista de atributos de cada entidade em um 
dicionario de dados 

Um atributo pode possuir uma cardinalidade, de maneira analoga a 
uma entidade em um relacionamento. A cardinalidade de um atributo define 
quantos valores deste atributo podem estar associados a uma ocorrencia da 
entidade /relacionamento a qual ele pertence. A representagao diagramatica 
da cardinalidade de atributos e derivada da representagao da cardinalidade 
de entidades em relacionamentos, conforme mostra a Figura 2.15. No caso de 
a cardinalidade ser (1,1) ela pode ser omitida do diagrama. Assim, o exemplo 
da Figura 2.15 expressa que nome e codigo sao atributos obrigatorios 
(cardinalidade minima - cada entidade possui no minimo um valor 
associado) e mono-valorados (cardinalidade maxima "1" - cada entidade possui 
no maximo um valor associado). Ja o atributo teiefone, e um atributo optional 
(cardinalidade minima 0) e midti-valorado (cardinalidade maxima n). 


CLIENTE 

i teiefone (0,n) 
O codigo 
O nome 


Figura 2.15: Cardinalidade de Atributos 



Assim como entidades possuem atributos, tambem relacionamentos po- 
dem possuir atributos. A Figura 2.16 mostra um DER no qual um relaciona- 
mento, ATUAQAO, possui um atributo, a funcao que um engenheiro exerce 
dentro de um projeto. Esta nao pode ser considerada atributo de 
ENGENEIEIRO, ja que um engenheiro pode atuar em diversos projetos exer- 
cendo diferentes fun^oes. Tambem, nao e atributo de PROJETO, ja que, em 
um projeto, podem atuar diversos engenheiros com funcoes diferentes. 



Codigo Nome FungSo Codiqo Tftulo 


Figura 2.16: Atributo de relacionamento n:n 

Outro exemplo de atributo em relacionamento, agora em um 
relacionamento l:n, e mostrado na Figura 2.17. Este diagrama modela vendas 
em uma organizagao comercial. Algumas vendas sao a vista, outras a prazo. 
Vendas a prazo sao relacionadas a uma financeira, atraves do relacionamento 
FINANCIAMENTO. Os atributos n Q de parcelas e taxa de juros sao atributos 
do relacionamento. 



Figura 2.17: Atributo de relacionamento l:n 

Estes dois atributos poderiam ter sido incluidos na entidade VENDA. 
Neste caso, seriam atributos opcionais, ja que nem toda venda e a prazo e 
possui estes atributos. Assim, preferiu-se usar o modelo da figura, exatamente 
para explicitar o fato de os atributos n Q de parcelas e taxa de juros 
pertencerem somente a vendas a prazo. 

2.3.1 Identificando entidades 

Cada entidade deve possuir um identificador. Um identificador e um conjunto 
de um ou mais atributos (e possivelmente relacionamentos, como visto 
abaixo) cujos valores servem para distinguir uma ocorrencia da entidade das 
demais ocorrencias da mesma entidade. 


PESSOA 


■# codigo 
O nome 
O enderego 


Figura 2. 1 8: Identificador simples 

O caso mais simples e o da entidade que possui um unico atributo como 
identificador. No DER, atributos identificadores sao representados por um 
circulo preto. No exemplo da Figura 2.18, o atributo codigo e identificador. 
Isso significa que cada pessoa possui um codigo diferente. Ja os atributos 
nome e enderego nao sao identificadores - o mesmo nome (ou o mesmo 
enderego) pode ser associados a diferentes pessoas. 

A Figura 2.19 mostra um exemplo no qual o identificador da entidade e 
composto por diversos atributos. Considera-se um almoxarifado de uma em- 
presa de ferragens organizado como segue. Os produtos ficam armazenados 
em prateleiras. Estas prateleiras encontram-se em armarios organizados em 
corredores. Os corredores sao numerados seqiiencialmente a partir de um e as 
prateleiras sao numeradas seqiiencialmente a partir de um dentro de um cor- 
redor. Assim, para identificar uma prateleira e necessario conhecer seu nu- 
mero e o numero do corredor em que se encontra. Para cada prateleira deseja- 
se saber sua capacidade em metros cubicos. 


PPATELEIPA 



capacidade 
numero do corredcr 
numero da prateleira 


Figura 2.19: Identificador composto 

Finalmente, ha casos em que o identificador de uma entidade e 
composto nao somente por atributos da propria entidade mas tambem por 
relacionamentos dos quais a entidade participa ( relacionamento identificador). 
Um exemplo deste caso e mostrado na Figura 2.20. Este diagrama apresenta 
empregados de uma organizagao, relacionados com os seus dependentes para 
fins de imposto de renda. Cada dependente esta relacionado a exatamente um 
empregado. Um dependente e identificado pelo empregado ao qual ele esta 
relacionado e por um numero de sequencia que distingue os diferentes 
dependentes de um mesmo empregado. No DER, o relacionamento usado 
como identificador e indicado por uma linha mais densa, conforme mostra a 
Figura 2.20. 


numero 



Figura 2.20: Relacionamento identificador 


Nesse caso, alguns autores dizem que a entidade DEPEN DENTE e uma 
entidade /raaz. O termo "fraca" deriva-se do fato de a entidade somente existir 
quando relacionada a outra entidade e de usar como parte de seu 
identificador, entidades relacionadas. Entretanto, os autores de livros mais 
recentes preferem nao utilizar o conceito, ja que as entidades chamadas 
"fracas" por este criterio podem, dependendo da realidade modelada, ser 
centrais a um modelo. Considere o fragmento de um DER sobre empresas, 
mostrado na Figura 2.21. No exemplo, e representada a divisao de grupos de 
empresas em empresas e de empresas em filiais de empresas. Para identificar 
um grupo de empresas e usado um codigo. Ja uma empresa e identificada 
pelo grupo ao qual esta relacionada e por um numero da empresa dentro do 
grupo. Finalmente, uma filial e identificada pela empresa a qual esta 
vinculada e por um numero de filial dentro da empresa. Pela definigao acima, 
tanto EMPRESA quanto FILIAL sao entidades fracas. Entretanto, ao 
considerarmos que a maior parte das entidades que eventualmente 
comporiam o restante do modelo estariam ligadas a EMPRESA ou FILIAL 
vemos que o conceito de "fraqueza" introduzido acima nao se aplica ao caso 
em questao. 



Figura 2.21: Entidades com relacionamentos identificadores 


identificador de entidade 

conjunto de atributos e relacionamentos 
cujos valores distinguem uma ocorrencia da 
entidade das demais 

O identificador de uma entidade, seja ele simples, composto por 
diversos atributos, ou composto por identificadores externos, deve obedecer 
duas propriedades: 

□ O identificador deve ser mvnimo. Isso significa que o identificador de 
uma entidade deve ser composto de tal forma que, retirando um dos 



atributos ou relacionamentos que o compoe, ele deixa de ser 
identificador. Exemplificando, na entidade PESSOA na Figura 2.18, o 
par codigo e nome poderia ser usado para distinguir uma ocorrencia de 
PESSOA das demais. Entretanto, estes atributos nao formam um 
identificador minirno, ja que codigo e suficiente para distinguir as 
ocorrencias de PESSOA. 

□ Cada entidade deve possuir um unico identificador. Em alguns casos, 
diferentes conjuntos de atributos podem servir para distinguir as 
ocorrencias da entidade. Exemplificando, a entidade EMPREGADO da 
Figura 2.22 poderia possuir como identificador tanto o atributo codigo, 
quanto o atributo CIC (identificador unico do contribuinte junto a 
Receita Federal). Cabe ao modelador decidir qual dos dois atributos sera 
usado como identificador da entidade. Alguns criterios para esta decisao 
aparecem mais adiante, no capitulo relativo ao projeto de BD a partir do 
modelo ER. 


EMPREGADO 
A CIC 


O codigo 
O nome 
O enderego 


Figura 2.22: Identificadores alternatives 

2.3.2 Identificando relacionamentos 

Em principio, uma ocorrencia de relacionamento diferencia-se das demais do 
mesmo relacionamento pelas ocorrencias de entidades que dela participam. 
Exemplificando, uma ocorrencia de ALOCAQAO (Figura 2.23) e identificada 
pela ocorrencia de ENGENHEIRO e pela ocorrencia de PROJETO que ela 
relaciona. Em outros termos, para cada par (engenheiro, projeto) ha no 
maximo um relacionamento de alocagao. 



Figura 2.23: Relacionamento identificado porsuas entidades 

Entretanto, ha casos nos quais entre as mesmas ocorrencias de entidade 
podem existir diversas ocorrencias de relacionamento. Um exemplo e o 
relacionamento CONSULTA entre entidades de MEDICO e de PACIENTE 
(Figura 2.24). Entre um determinado medico e um determinado paciente 
podem haver diversas consultas. Neste caso, e necessario algo que distinga 
uma consulta entre um medico e seu paciente das demais consultas entre este 
medico e seu paciente. A diferenciagao da-se atraves de atributos identificadores 
de relacionamentos. No caso da Figura 2.24, o atributo identificador do 
relacionamento e data/hora. 



w data/hora 


Figura 2.24: Identificador de relacionamento 

Assim, de forma geral, um relacionamento e identificado pelas 
entidades dele participantes, bem como pelos atributos identificadores 
eventualmente existentes. 

2.4 Generalizaqao/especializaqao 

Alem de relacionamentos e atributos, propriedades podem ser atribuidas a 
entidades atraves do conceito de generalizagao/especializagao. Atraves deste 
conceito e possivel atribuir propriedades particulares a um subconjunto das 
ocorrencias ( especializadas ) de uma entidade generica. O simbolo para 
representar generalizagao/especializagao e um triangulo isosceles, conforme 
mostra a Figura 2.25. A generalizagao/especializagao mostrada nesta figura 
expressa que a entidade CLIENTE e dividida em dois subconjuntos, as 
entidades PESSOA FISICA e PESSOA JURIDICA cada um com propriedades 
proprias. 

Associada ao conceito de generalizagao/especializagao esta a ideia de 
heranga de propriedades. Herdar propriedades significa que cada ocorrencia da 
entidade especializada possui, alem de suas proprias propriedades (atributos, 
relacionamentos e generalizagSes/especializagSes), tambem as propriedades 
da ocorrencia da entidade generica correspondente. Assim, segundo o DER 
da Figura 2.25, a entidade PESSOA FISICA possui, alem de seus atributos 
particulares, CIC e sexo, tambem todas as propriedades da ocorrencia da 
entidade CLIENTE correspondente, ou seja, os atributos nome e codigo, o seu 
identificador (atributo codigo), bem como o relacionamento com a entidade 
FILIAL. Resumindo, o diagrama expressa que toda pessoa fisica tern como 
atributos nome, codigo, CIC e sexo, e identificada pelo codigo e esta 
obrigatoriamente relacionada a exatamente uma filial. Da mesma maneira, 
toda pessoa juridica tern como atributos nome, codigo, CGC e tipo de 
organizagao, e identificada pelo codigo e esta obrigatoriamente relacionada a 
exatamente uma filial. 


no me 



CIC sexo 


CGC tipo de 
organizapao 


Figura 2.25: Generalizagao/especializagao 

A generalizapao/ especializapao pode ser classificada em dois tipos, total 
ou parcial, de acordo com a obrigatoriedade ou nao de a uma ocorrencia da 
entidade generica corresponder uma ocorrencia da entidade especializada. 

Em uma generalizapao /especializapao total para cada ocorrencia da 
entidade generica existe sempre uma ocorrencia em uma das entidades 
especializadas. Esse e o caso do exemplo da Figura 2.25, no qual a toda 
ocorrencia da entidade CLIENTE corresponde uma ocorrencia em uma das 
duas especializapSes. Esse tipo de generalizapao /especializapao e simbolizado 
por um "t" conforme mostrado na Figura 2.26. 



Figura 2.26: Generalizagao/especializagao total 

Em uma gener a 1 i za pa o / especi a 1 i za pa o parcial, nem toda ocorrencia da 
entidade generica possui uma ocorrencia correspondente em uma entidade 
especializada. Esse e o caso do exemplo da Figura 2.27, no qual nem toda 
entidade FUNCIONARIO possui uma entidade correspondente em uma das 
duas especializapoes (nem todo o funcionario e motorista ou secretarial Esse 
tipo de generalizapao/especializapao e simbolizado por um “p" conforme 
mostrado na figura. Usualmente, quando ha uma especializapao parcial, na 


entidade generica (no caso do exemplo, em FUNCIONARIO) aparece um 
atributo que identifica o tipo de ocorrencia da entidade generica (no caso do 
exemplo, trata-se do atributo tipo de funcionario). Este atributo nao e 
necessario no caso de especializagSes totais, ja que a presenga da ocorrencia 
correspondente a entidade generica em uma de suas especializagSes e 
suficiente para identificar o tipo da entidade. 



Figura 2.27: Generalizagao/especializagao parcial 

Uma entidade pode ser especializada em qualquer numero de entidades, 
inclusive em uma unica. Exemplificando, se no exemplo da Figura 2.27, ape- 
nas os motoristas possuissem propriedades particulares, haveria apenas uma 
entidade especializada, a de motoristas. 

Alem disso, nao ha limite no numero de niveis hierarquicos da 
generalizagao/especializagao. Uma entidade especializada em uma 
generalizagao/especializagao, pode, por sua vez, ser entidade generica em 
uma outra generalizagao/especializagao. E admissivel, inclusive, que uma 
mesma entidade seja especializagao de diversas entidades genericas (a 
chamada heranga multipla). A Figura 2.28 apresenta um DER em que aparecem 
multiplos niveis de generalizagao/especializagao, bem como o conceito de 
heranga multipla. Exemplificando, uma entidade BARCO e uma 
especializagao de um VEICULO AQUATICO, que por sua vez e uma 
especializagao de VEICULO. Assim um barco tern, alem de suas propriedades 
especificas, tambem as propriedades de um veiculo aquatico, bem como as 
propriedades de um veiculo em geral. O exemplo de heranga multipla 
aparece na entidade VEICULO ANFIBIO. Um veiculo anfibio, possui, alem de 
suas propriedades especificas, tanto as propriedades de um veiculo aquatico, 
quanto as propriedades de um veiculo terrestre, ja que e especializagao destas 
duas ultimas entidades. 

A generalizagao /especializagao como tratada neste livro e exclusivci. 
Generalizagao /especializagao exclusiva significa que uma ocorrencia de 
entidade generica aparece, para cada hierarquia generalizagao /especializagao, 
no maximo uma vez, nas folhas da arvore de generalizagao /especializagao. 
Exemplificando, na Figura 2.28, um veiculo e automovel ou veiculo anfibio ou 
barco e somente um destes. 



Figura 2.28: Generalizagao/especializagao em multiplos niveis e com 
heranga multipla 

Ha autores que permitem tambem especializagSes nao exclusivas. Um 
exemplo e mostrado na Figura 2.29. Neste diagrama, considera-se o conjunto 
de pessoas vinculadas a uma universidade. Neste caso, a especializagao nao e 
exclusiva, ja que a mesma pessoa pode aparecer em multiplas especializagSes. 
Uma pessoa pode ser professor de um curso e ser aluno em outro curso, ou 
ser aluno de pos-graduagao. Por outro lado, uma pessoa pode acumular o 
cargo de professor em tempo parcial com o cargo de funcionario, ou, ate 
mesmo, ser professor de tempo parcial em dois departamentos diferentes, 
sendo portanto duas vezes professor. O principal problema que este tipo de 
generalizagao/especializagao apresenta e que neste caso as entidades 
especializadas nao podem herdar o identificador da entidade generica. No 
caso, o identificador de pessoa nao seria suficiente para identificar 
professores, ja que uma pessoa pode ser multiplas vezes professor. 



Figura 2.29: Generalizagao/especializagao nao exclusiva 

Em casos como o mostrado, usa-se o conceito de relacionamento, ao 
inves do conceito de generalizagao/especializagao. O modelo deveria conter 
tres relacionamentos, associando a entidade PESSOA com as entidades 
correspondentes a cada um dos papeis de PESSOA (PROFESSOR, 
FUNCIONARIO e ALUNO). 


2.5 Entidade associativa 


Um relacionamento e uma associagao entre entidades. Na modelagem ER nao 
foi prevista a possibilidade de associar uma entidade com um relacionamento 
ou entao de associar dois relacionamentos entre si. Na pratica, quando esta-se 
construindo um novo DER ou modificando um DER existente, surgem 
situates em que e desejavel permitir a associagao de uma entidade a um 
relacionamento. A titulo de exemplo, considere-se o diagrama da Figura 2.30. 



Figura 2.30: DER a ser modificado 

Suponha que seja necessario modificar este diagrama com a adi<;ao da 
informagao de que, em cada consulta, um ou mais medicamentos podem ser 
prescritos ao paciente. Para tal, criar-se-ia uma nova entidade, 
MEDICAMENTO. A questao agora e: com que entidade existente deve estar 
relacionada a nova entidade? Se MEDICAMENTO fosse relacionado a 
MEDICO, ter-se-ia apenas a inform a^ao de que medico prescreveu que 
medicamentos, faltando a informagao do paciente que os teve prescritos. Por 
outro lado, se MEDICAMENTO fosse relacionado a PACIENTE, faltaria a 
informagao do medico que prescreveu o medicamento. Assim, deseja-se 
relacionar o medicamento a consulta, ou seja deseja-se relacionar uma 
entidade (MEDICAMENTO) a um relacionamento (CONSULTA), o que nao 
esta previsto na abordagem ER. Para tal, foi criado um conceito especial, o de 
entidade associativa. Uma entidade associativa nada mais e que a redefinigao de 
um relacionamento, que passa a ser tratado como se fosse tambem uma 
entidade. Graficamente, isso e feito como mostrado na Figura 2.31. O 
retangulo desenhado ao redor do relacionamento CONSULTA indica que este 
relacionamento passa a ser visto como uma entidade (associativa, ja que 
baseada em um relacionamento). Sendo CONSULTA tambem uma entidade, e 
possivel associa-la atraves de relacionamentos a outras entidades, conforme 
mostra a figura. 



Figura 2.31: Entidade associativa 

Observe-se que, caso nao se desejasse usar o conceito de entidade 
associativa, seria necessario transformar o relacionamento CONSULTA em 
uma entidade, que entao poderia ser relacionada a MEDICAMENTO, 
conforme mostrado na Figura 2.32. 



Figura 2.32: Substituindo relacionamento por entidade 

Na figura, o relacionamento foi substituido por uma entidade homo- 
nima, junto com dois relacionamentos (parte representada em linhas densas). 
Observe-se que, para manter equivalencia com o diagrama anterior, uma con- 
sulta esta relacionada com exatamente um medico e exatamente um paciente 
(cardinalidade minima e maxima e um). Uma consulta e identificada pelo pa- 
ciente e pelo medico a ela ligados. Tendo substituido o relacionamento 
CONSULTA pela entidade, basta relacionar a entidade CONSULTA com a en- 
tidade MEDICAMENTO. Observe-se que o diagrama da Figura 2.32 e equiva- 
lente ao diagrama da Figura 2.31. Equivalente aqui significa que ambos geram 


o mesmo banco de dados relational. A transformagao de modelos ER em des- 
cribes de BD relacionais, necessaria a compreensao do conceito de equivalen- 
ce, e apresentada em um dos proximos capitulos. 

2.6 Esquemas graficos e textuais de modelos ER 

A descrigao de um modelo e chamada, na terminologia de banco de dados, de 
o esquema do banco de dados. 

Ate este ponto os esquemas ER sempre foram diagramas ER, isto e 
sempre estao apresentados na forma grafica. A Figura 2.33 resume os 
simbolos usados neste livro para a representagao grafica de esquemas ER. 

Um esquema ER pode ser um texto. Na Figura 2.34 aparece a sintaxe de 
uma linguagem textual para defini^ao de esquemas ER. A sintaxe e dada na 
forma de uma gramatica BNF 3 . Nesta sintaxe, sao usadas as seguintes 
convengSes: colchetes denotam opcionalidade, chaves denotam repetigao, o 
sufixo LI ST A denota uma sequencia de elementos separados por virgulas e o 
sufixo NOME denota identificadores. 


3 Se voce nao sabe o que e uma gramatica BNF consulte um livro sobre linguagens de 
programa^ao ou sobre construgao de compiladores. 


Conceito 


Simbolo 


Entidade 



Atributo 

identificador 




Reiacionamento 

identificador 




Figura 2.33: Sfmbolos usados na construgao de esquemas ER 

A Figura 2.35 apresenta um esquema ER textual correspondente ao 
esquema ER grafico da Figura 2.20. Note-se que a representagao grafica e a 
textual aqui usadas nao sao exatamente equivalentes. A notagao textual, em 
nosso caso, e mais rica, pois inclui a possibilidade de definir um tipo de 
atributo (declaragao DECL_TIPO). 

Na pratica e usual combinar as duas formas de representar esquemas 
ER: a diagramatica e a textual. Escolhe-se a forma de representar de acordo 
com a sua adequagao. Entidades e relacionamentos, bem como hierarquias de 
general izacjao/ especializagao sao normalmente representadas de forma 
grafica, pois a representagao textual de grafos e dificil de ler. Ja os atributos 
das entidades e dos relacionamentos, bem como a definicao de atributos 
identificadores e feita de forma textual, pois sobrecarregaria o diagrama. 


ESQUEMA ->• Esquema: ESQUEMA NOME 
SEQAO_ENTIDADE 
SEQAO_GENEFlALIZAQAO 
S EQ AO_ENT_AS S OC I ATI VA 
S EQAO_RELACION AMENTO 

SEQAO_ENTIDADE-> {DECL_ENT} 

DECL_ENT -► Entidade: ENTIDADE NOME 
[S EQ AO_ATRI B U TO] 

[SEgAOJDENTIFICADOR] 

SEgAO_ATRIBUTO -► Atributos: {DECL_ATRIB} 

DECL_ATRIB -► [(M IN CARD ,M AX_C ARD)] ATRIBUTOJSIOME [: DECL_TIPO] 
M INBOARD -> 0 | 1 
MAX_CARD -► 1 | n 

DECL_TIPO ->• inteiro | real | boolean | texto(INTEIRO) | 
enumeragao(LISTA_VALORES) 

SEgAOJDENTIFICADOR -+ Identificadores: {DECLJDENT} 

DECLJDENT-*- {IDENTIFICADOR} 

IDENTIFICADOR -► ATRIBUTO_NOME | 

ENTIDADEJMOME (via RELACIONAMENTOJMOME) 

S EgAO_GEN ERALIZAgAO > [DECL_HIERARQUIAJ3EN] 

D ECL_H IERARQU IA_GEN -► Generalizagao [(COBERTURA)]: NOMEJ3EN 

PAI: NOME_ENTIDADE 
FILHO: LISTA NOME_ENTIDADE 

COBERTURA -►tip 

S Eg AO_ENT_AS S OC I ATI VA ->• [DECL_ENT_ASSOC] 

D EC L_E N T_AS S OC ->• EntidadeAssociativa: NOMERELAC ION AMENTO 

SEgAO_RELACIONAMENTO -> {DECL_RELACION} 

DECL_RELACION -> Relacionamento: NOME_RELACION AMENTO 
Entidades: {DECL_ENT-RELACIONADA} 

[Atributos: {DECL_ATRIB}] 

[Identificadores: {DECLJDENT}] 

DECL_ENT-RELACIONADA -> [(CARD_MIN,CARD_MAX)] NOME ENTIDADE 


Figura 2.34: Gramatica BNF de uma linguagem para definigao de esquema 
ER textual 



Esquema: EMP_DEP 

Entidade: EMPREGADO 

Atributos: CODIGO: inteiro 
Identificadores: CODIGO 

Entidade: DEPENDENTE 

Atributos: NUMERO_SEQUENCIA: inteiro 
NOME: texto(50) 

Identificadores: EMPREGADO via EMP_DEP 
NUMERO_SEQUENCIA 

Relacionamento: EMP_DEP 

Entidades: (1 ,1 ) EMPREGADO 
(0,n) DEPENDENTE 

Figura 2.35: Esquema ER textual correspondente a Figura 2.20 

Exercicios 

Exercfcio 2.1: De ao menos cinco exemplos dos conceitos basicos da aborda- 
gem ER apresentados neste capftulo: entidade, relacionamento, atributo, ge- 
neralizagao/ especializagao. 

Exercfcio 2.2: Explique a diferenca entre uma entidade e uma ocorrencia de 
entidade. Exemplifique. 

Exercfcio 2.3: O que e o papel de uma entidade em um relacionamento. 
Quando e necessario especificar o papel das entidades de um relacionamento? 
Exercfcio 2.4: Considere o relacionamento CASAMENTO que aparece no DER 
da Figura 2.7. Segundo este DER o banco de dados poderia conter um casa- 
mento em que uma pessoa esta casada consigo mesma? O DER permite que a 
mesma pessoa aparega em dois casamentos diferentes, uma vez como marido 
e outra vez com esposa? Caso uma destas situates possa ocorrer, como deve- 
ria ser modificado o DER para impedi-las? 

Exercfcio 2.5: Confeccione um possfvel diagrama de ocorrencias para o relaci- 
onamento SUPERVISAO (Figura 2.8) e suas respectivas entidades. 

Exercfcio 2.6: Confeccione um possfvel diagrama de ocorrencias para o relaci- 
onamento COMPOSIQAO (Figura 2.9) e suas respectivas entidades. 

Exercfcio 2.7: Mostre como o modelo ER da Figura 2.11 pode ser representado 
sem uso de relacionamentos ternarios, apenas usando relacionamentos bina- 
rios. 

Exercfcio 2.8: De um exemplo de um relacionamento ternario. Mostre como a 
mesma realidade pode ser modelada somente com relacionamentos binarios. 
Exercfcio 2.9: Para o exemplo de relacionamento ternario da questao anterior, 
justifique a escolha das cardinalidades minima e maxima. 

Exercfcio 2.10: Considere o DER da Figura 2.12. Para que a restrigao de cardi- 
nalidade minima seja obedecida, que ocorrencias de entidade devem existir 
no banco de dados, quando for inclufda uma ocorrencia de EMPREGADO? E 
quando for inclufda uma ocorrencia de MESA? 

Exercfcio 2.11: Construa um DER que modela a mesma realidade que a mos- 
trada no DER da Figura 2.16, usando apenas relacionamentos l:n. 


Exercfcio 2.12: Considere o relacionamento EMPREGADO-DEPENDENTE 
que aparece na Figura 2.20. Considere que um dependente de um empregado 
possa ser tambem empregado. Como o modelo deveria ser modificado para 
evitar o armazenamento redundante das informagSes das pessoas que sao 
tanto dependentes quanto empregados? 

Exercfcio 2.13: Construa um DER em que o conceito de entidade associativa e 
usado. 

Exercfcio 2.14: De ao menos tres exemplos de entidades com relacionamentos 
identificadores (entidades fracas). 

Exercfcio 2.15: Considere o exemplo da Figura 2.13. Modifique as cardinali- 
dades mfnimas de forma a especificar o seguinte: 

□ Um curso nao pode estar vazio, isto e, deve possuir ao menos uma disci- 
plina em seu currfculo 

□ Um aluno, mesmo que nao inscrito em nenhum curso, deve permanecer 
por algum tempo no banco de dados. 

Exercfcio 2.16: Sem usar atributos opcionais, nem atributos multi-valorados, 
construa um DER que contenha as mesmas informagSes do DER da Figura 
2.15 

Exercfcio 2.17: O DER da Figura 2.29 modela uma generaliza- 
gao/especializagao nao exclusiva. Como dito no texto do capftulo que des- 
creve este DER, generalizagSes/especializagSes deste tipo nao sao usadas 
neste livro. Construa um DER que modela a realidade descrita sem usar o 
conceitos de generalizagao/especializagao nao exclusiva. 

Exercfcio 2.18: A Figura 2.36 apresenta um modelo de dados para uma 
farmacia. Descreva em portugues tudo o que esta representado neste 
diagrama. 

Exercfcio 2.19: Invente nomes para os relacionamentos da Figura 2.36. 
Exercfcio 2.20: De uma justificativa para as cardinalidades mfnimas do 
relacionamento entre FORNECEDOR e FABRICANTE no DER da Figura 2.36. 
Exercfcio 2.21: Explique o significado das cardinalidades minima e maxima 
do relacionamento ternario (entre MEDICAMENTO, VENDA e RECEITA 
MEDICA) no DER da Figura 2.36. 

Exercfcio 2.22: Em princfpio, uma venda deve envolver ao menos um 
produto. Entretanto, isso nao e exigido pelas cardinalidades mfnimas dos 
relacionamentos entre VENDA e MEDICAMENTO e entre VENDA e 
PERFUMARIA no DER da Figura 2.36. Explique porque. 

Exercfcio 2.23: Para cada entidade e cada relacionamento no DER da Figura 
2.36 defina, quando possfvel, atributos. Para cada entidade, indique o(s) 
atributo(s) identificador(es). 

Exercfcio 2.24: Escreva um esquema ER textual para o esquema diagramatico 
da Figura 2.36. 



Figura 2.36: Diagrama ER de uma farmacia 



Figura 2.37: Diagrama ER para sistema de recursos humanos 




















Exercicio 2.25:A Figura 2.37 apresenta um DER de parte de um sistema de 
recursos humanos em uma organizacao. Descreva em portugues tudo que 
esta representado neste diagrama. 

Exercicio 2.26: Para cada entidade e cada relacionamento do DER da Figura 
2.37 defina, quando possivel, atributos. Para cada entidade, indique o(s) 
atributo(s) identificador(es). 

Exercicio 2.27: Escreva um esquema ER textual para o esquema diagramatico 
da Figura 2.37 

Exercicio 2.28: De acordo com o DER da Figura 2.37, que agSes devem ser 
tomadas ao excluir-se do banco de dados uma secretaria? 

Exercicio 2.29: De acordo com o DER da Figura 2.37, uma secretaria ou um 
engenheiro nao podem ser gerentes. Porque? Como o DER deveria ser 
modificado para permitir que tanto uma secretaria, quanto um engenheiro 
pudessem ser tambem gerentes? 
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Capitulo 

3 

Construindo 
modelos ER 


No capitulo anterior, vimos como um diagrama ER e composto. Neste capi- 
tulo, vamos nos concentrar na construcao de modelos ER, isto e, no problema 
de como, dada uma determinada realidade, obter o modelo ER. 

O capitulo inicia apresentando uma coletanea de conselhos praticos e 
heuristicas a usar durante a modelagem conceitual. A seguir sao apresentadas 
notates alternativas a de Peter Chen para confeccao de diagramas ER. O ca- 
pitulo finaliza apresentando um processo de modelagem e discutindo alter- 
nativas a este processo. 



3.1 Propriedades de modelos ER 


Nesta segao, discutimos algumas propriedades de modelos ER que sao im- 
portantes ter em mente quando da modelagem ER. 

3.1.1 Um modelo ER e um modelo formal 

Um DER e um modelo formal, preciso, nao ambiguo. Isto significa que dife- 
rentes leitores de um mesmo DER devem sempre entender exatamente o 
mesmo. Tanto e assim, que um DER pode ser usado como entrada a uma fer- 
ramenta CASE 4 na geragao de um banco de dados relacional. Por isso, e de 
fundamental importancia que todos os envolvidos na confcccao e uso de dia- 
gramas ER estejam treinados na sua perfeita compreensao. 

Observa-se em certas organizagbes, que modelos ER sao sub-utilizados, 
servindo apenas como ferramenta para aprcscntacao informal de ideias. Isso 
pode ser evitado com treinamento formal de todos envolvidos na modelagem 
e projeto do banco de dados. 

Note-se que e importante que efetivamente todos os que manipulam 
modelos ER estejam treinados em sua compreensao. O fato de um DER ser 
grafico e intuitivo pode transmitir a falsa impressao de ser compreensivel ate 
por alguem nao treinado. 

Para exemplificar o tipo de problemas que surgem ao usar diagramas ER 
sem treinar as pessoas envolvidas, descrevo uma situagao que ja observei em 
algumas organizacoes. Os tecnicos em computacao da organizacao desenvol- 
veram um DER a partir de sua compreensao sobre o sistema a ser construido, 
obtida a partir de entrevistas com os futuros usuarios do sistema. Para validar 
o modelo, este foi apresentado aos usuarios. Entretanto, os usuarios nao fo- 
ram treinados em modelagem e compreendiam o modelo apenas como uma 
dcscricao grafica informal. Os usuarios concordaram com o DER que lhes foi 
apresentado. Mais tarde, ja com o banco de dados em funcionamento, desco- 
briu-se que os usuarios nao haviam entendido efetivamente o que foi mode- 
lado. O BD implementado nao era exatamente aquele desejado pelos usuarios, 
apesar de corresponder exatamente ao DER apresentado. Assim, para que 
modelos ER possam atingir seus objetivos, e necessario treinamento formal. 
Nao estou sugerindo aqui que os usuarios tenham que ser treinados como 
modeladores. Basta que eles recebam algumas horas de treinamento na leitura 
e compreensao de diagramas ER. 

3.1.2 Abordagem ER tern poder de expressao limitado 

Em um modelo ER, sao apresentadas apenas algumas propriedades de um 
banco de dados. Em realidade, a linguagem dos DER e uma linguagem muito 
pouco poderosa e muitas propriedades desejaveis do banco de dados necessi- 
tam ser anotadas adicionalmente ao DER. Abaixo mostramos dois exemplos 


4 Ferramenta CASE: software que da suporte a construcao de software (CASE vem do 
ingles "computer aided software engineering" que significa "engenharia de software 
suportada por computador") 



de DER, ja vistos no capftulo anterior, para salientar o quao incompletos sao 
estes modelos. 



Figura 3.1: DER e diagrama de ocorrencias para CASAMENTO 

A Figura 3.1 mostra o DER que modela pessoas e casamentos ja mos- 
trado no capftulo anterior. Ao lado, sao mostrados possfveis ocorrencias de 
PESSOA e CASAMENTO. Entretanto, as ocorrencias de CASAMENTO nao cor- 
respondent ao nosso conhecimento da realidade (pelo menos se considerar- 
mos a legislagao brasileira). A pessoa p3 aparece em dois casamentos, uma 
vez no papel de esposa e outra vez no papel de marido. Alem disso, a pessoa 
p5 aparece casada consigo mesma (o que poderia ser bom para um contribu- 
inte do imposto de renda - ter-se-ia os descontos referentes a um dependente, 
sem incorrer nos custos referentes a um dependente). Assim, para fazer com 
que o DER corresponda a realidade que deseja-se modelar, e necessario modi- 
fica-lo ou entao definir restricoes adicionais. No caso em questao, e possfvel 
modificar o DER para excluir os casamentos indesejaveis (ver exercfcio no ca- 
pftulo anterior). 

Aqui cabe a pergunta: ate onde deve ser modificado um DER para in- 
troduzir restricSes de integridade? A resposta nao e trivial. Aqui entra o bom 
senso do modelador. E necessario lembrar o objetivo que se tern ao construir 
um diagrama ER: o de projetar um banco de dados. Neste contexto, o DER 
nada mais e do que uma descripao abstrata das estruturas do banco de dados 
(das tabelas, no caso de um banco de dados relacional). O objetivo do dia- 
grama nao e o de especificar todas restricSes de integridade. Assim, somente 
sao inclufdas construcSes em um DER, quando estas possuem uma corres- 
pondence no banco de dados a ser implementada. ConstrucSes artificiais, isto 
e, construcSes inclufdas no modelo apenas para satisfazer determinadas res- 
tricoes de integridade sao indesejaveis, pois distorcem os objetivos que se tern 
ao construir o DER. 

Entretanto, ha situacoes em que, mesmo atraves de modificacoes no 
DER, e impossfvel incluir no diagrama as restricSes desejadas. 



Figura 3.2: Relacionamento recursivo 

A Figura 3.2 apresenta um exemplo de um DER modelando empregados 
e a hierarquia de supervisao em uma organizagao. O relacionamento 
SUPERVISAO possui cardinalidade l:n indicando que um empregado pode 
supervisionar muitos outros, mas possui no maximo um supervisor. Como 
esta especificado, o modelo admite o diagrama de ocorrencias que aparece na 
figura. Os relacionamentos mostrados informam que o empregado el e su- 
pervisor do empregado e3, que por sua vez e supervisor de e5, o qual, por sua 
vez e supervisor de el. Isso obviamente contraria nosso conhecimento sobre a 
realidade modelada, ja que, em uma hierarquia de supervisao, nao e permi- 
tido que um superior hierarquico (no caso el) aparega como supervisionado 
em um nivel mais baixo da hierarquia (no caso, el aparece como supervisio- 
nado de e5). Essa restrigao, ao contrario do exemplo do casamento apresen- 
tado acima, nao e possivel de se introduzir no DER atraves de modificagoes. 
O problema e que a restricao e uma restrigao de integridade recursiva e estas 
nao podem ser representadas atraves de diagramas ER. Neste caso, resta ape- 
nas especificar a restricao a parte do DER. 

3.1.3 Diferentes modelos podem ser equivalentes 

Na pratica, muitas vezes observa-se analistas em acirradas discussbes a fim de 
decidir como um determinado objeto da realidade modelada deve aparecer 
no modelo. As vezes, tais discussoes sao absolutamente superfluas, pois os 
diferentes modelos ER, em qualquer das opcoes defendidas pelos diferentes 
analistas, geram o mesmo banco de dados. 

Ha um conceito de equivalencia entre modelos ER. De maneira informal, 
diz-se que dois modelos sao equivalentes, quando expressam o mesmo, ou 
seja quando modelam a mesma realidade. 

Para definir o conceito de equivalencia de forma mais precisa, e necessa- 
rio considerar o BD que e projetado a partir do modelo ER. Para fins de pro- 
jeto de BD, dois modelos ER sao equivalentes, quando ambos geram o mesmo 
esquema de BD. Assim, para analisar se dois modelos sao equivalentes, e ne- 


cessario considerar um conjunto de regras de tradugao de modelos ER para 
modelos logicos de BD. Para os fins deste texto, vamos considerar as regras de 
tradugao de modelo ER para modelo relacional apresentadas no Capitulo 5. 
Dois modelos ER sao equivalentes caso gerem o mesmo modelo de BD relaci- 
onal atraves do uso das regras de tradu^ao apresentadas no Capitulo 5. 
Quando falamos "o mesmo modelo de BD relacional" estamos falando de 
bancos de dados que, abstraindo de diferengas de nomes de estruturas (tabe- 
las, atributos, ...) tenham a mesma estrutura. 

E claro que para entender perfeitamente este conceito de equivalencia de 
modelos, o leitor deve conhecer as regras de tradugao apresentadas no Capi- 
tulo 5. Mesmo assim, considerando a definicao informal de equivalencia (dois 
modelos que expressam o mesmo), e possivel compreender alguns casos da 
aplicagao do conceito. 

Um caso e o da equivalencia entre um modelo que representa um con- 
ceito atraves de um relacionamento n:n e outro modelo que representa o 
mesmo conceito atraves de uma entidade. Um exemplo sao os modelos ER 
apresentados na Figura 3.3, onde o relacionamento CONSULTA foi transfor- 
mado em uma entidade. 

Os dois modelos sao equivalentes, pois expressam o mesmo e geram o 
mesmo banco de dados. 



c6d\qo nome data/hora codigo nome 

a) CONSULTA como relacionamento n:n 



data/hora 


b) CONSULTA como entidade 

Figura 3.3: Transformando relacionamento n:n em entidade 

A transformagao de um relacionamento n:n em entidade segue o se- 
guinte processo: 


1. O relacionamento n:n e representado como uma entidade. 

2. A entidade criada e relacionada as entidades que originalmente participa- 
vam do relacionamento. 

3. A entidade criada tem como identificador: 

> as entidades que originalmente participavam do relacionamento 

> os atributos que eram identificadores do relacionamento original (caso 
o relacionamento original tivesse atributos identificadores) 

4. As cardinalidades da entidade criada nos relacionamentos de que parti- 
cipa e sempre (1,1). 

5. As cardinalidades das entidades que eram originalmente associadas pelo 
relacionamento transformado em entidade sao transcritas ao novo modelo 
conforme mostrado na Figura 3.3. 

Como um relacionamento n:n pode ser transformado em entidade, e 
possivel construir modelos sem relacionamentos n:n. Neste fato, baseiam-se 
diversas variantes da abordagem ER, que excluem relacionamentos n:n, ou 
excluem apenas relacionamentos n:n com atributos. Um exemplo sao varias 
abordagens baseadas na Engenharia de InformacSes (ver Secao 3.4.1. 1). 

Um outro caso de equivalencia, e entre um relacionamento de cardinali- 
dade 1 :1 e com cardinalidade minima "1 " em ambos os lados pode ser subs- 
tituido por uma unica entidade. 

3.2 IDENTIFICANDO CONSTRUQOES 

Apenas observando um determinado objeto da realidade modelada, e dificil 
determinar se tal objeto deve ser modelado como uma entidade, um atributo 
ou um relacionamento. Para definir que construgao de ER sera usada na mo- 
delagem do objeto, e necessario conhecer o seu contexto, isto e, o modelo 
dentro do qual ele aparece. Assim, a recomendagao geral que se da para a 
identificagao de objetos e a de considerar a decisao por um ou outro tipo de 
representagao no modelo (entidade, relacionamento, atributo) como sujeita a 
alteragao durante a modelagem. Nao e aconselhavel despender um tempo ex- 
cessivo em longas discussbes sobre como modelar um objeto. O proprio des- 
envolvimento do modelo e o aprendizado sobre a realidade irao refinando e 
aperfeicoando o modelo. Mesmo assim, existem alguns indicativos para a es- 
colha de construgSes de modelagem. Estes indicativos passam a ser descritos 
a seguir. 

3.2.1 Atributo versus entidade relacionada 

Uma questao que as vezes surge na modelagem de um sistema e entre mode- 
lar um objeto como sendo um atributo de uma entidade ou como sendo uma 
entidade autonoma relacionada a essa entidade. 

Exemplificando, no caso de uma industria de automoveis, como deve- 
mos registrar a cor de cada automovel que sai da linha de produgao? Caso 
considerarmos que cada automovel possui uma unica cor predominante, 
pode-se pensar em modelar a cor como um atributo da entidade 
AUTOMOVEL (primeira op^ao da Figura 3.4). Outra opgao seria modelar a cor 


como uma entidade autonoma, que esta relacionada a entidade AUTOMOVEL 
(segunda opgao da Figura 3.4). 



Figura 3.4: Escolhendo entre atributo e entidade relacionada 
Alguns criterios para esta decisao sao: 

□ Caso o objeto cuja modelagem esta em discussao esteja vinculado a ou- 
tros objetos (atributos, relacionamentos, entidades genericas ou especia- 
lizadas), o objeto deve ser modelado como entidade, ja que um atributo 
nao pode ter atributos, nem estar relacionado a outras entidades, nem 
ser generalizado ou especializado. Caso contrario, o objeto pode ser mo- 
delado como atributo. Assim, no caso do exemplo das cores dos auto- 
moveis, poder-se-ia optar por modelar a cor como uma entidade, caso se 
tivesse que registrar no banco de dados os possiveis fabricantes da tinta 
da referida cor (entidades relacionadas a cor), ou caso se quisesse regis- 
trar as datas de inicio e fim (atributos) do uso de uma determinada cor. 
Caso nao houvesse nenhum objeto relacionado a cor do automovel, po- 
der-se-ia modela-la como atributo da entidade automovel. 

□ Quando o conjunto de valores de um determinado objeto e fixo durante 
toda a vida do sistema ele pode ser modelado como atributo, visto que o 
dominio de valores de um atributo e imutavel. Quando existem transa- 
g5es no sistema que alteram o conjunto de valores do objeto, o mesmo 
nao deve ser modelado como atributo. Assim, retomando o exemplo das 
cores dos automoveis, caso existissem transagSes de criagao/eliminagao 
de cores, seria preferivel a modelagem de cor como entidade relacionada 
a entidade automovel. 

3.2.2 Atributo versus generaliza^ao/especializa^ao 

Um outro conflito de modelagem para o qual ha algumas regras de cunho 
pratico e entre modelar um determinado objeto (por, exemplo, a categoria 
funcional de cada empregado de uma empresa) como atributo (categoria fun- 
cional como atributo da entidade EMPREGADO - Figura 3.5) ou atraves de 
uma especializagao (cada categoria funcional corresponde a uma especializa- 
gao da entidade empregado - Figura 3.6). 

Uma especializagao deve ser usada quando sabe-se que as classes espe- 
cializadas de entidades possuem propriedades (atributos, relacionamentos, 
generalizagoes, especializagSes) particulares. Assim, no caso do exemplo 
acima, faz sentido especializar a entidade empregado de acordo com a catego- 
ria funcional, no caso de as classes particulares possuirem atributos ou relaci- 
onamentos proprios (um exemplo e o caso da Figura 3.5). 


Ainda no exemplo dos empregados, o sexo do empregado e melhor mo- 
delado como atributo de empregado, caso nao existam propriedades particu- 
lares de homens e mulheres a modelar na realidade considerada. 


categoria 

funcional 



Figura 3.5: Modelando categoria funcional como atributo 


no me codigo 



numero da data de CK EA 

carteira de expirapao da 
habilitapao carteira de 
habilitapao 

Figura 3.6: Modelando categoria funcional como especializagao 

3.2.3 Atributos opcionais e multi-valorados 

Conforme vimos no capitulo anterior (Secao 2.3), atributos podem ser opcio- 
nais (nem toda ocorrencia da entidade possui um valor do atributo) ou multi- 
valorados. Entretanto, quando se inicia o processo de modelagem e aconselha- 
vel tentar restringir-se ao uso de atributos obrigatorios e mono-valorados pelas 
razbes abaixo listadas. 

3.2.3.1 Atributo opcional 

Em muitos casos, atributos opcionais indicam subconjuntos de entidades que 
sao modelados mais corretamente atraves de especializagSes. O DER da 
Figura 3.7 apresenta uma entidade com diversos atributos opcionais. Segundo 
este DER, nem todo empregado possui um registro no CREA (Conselho Regi- 
onal de Engenharia e Arquitetura), nem todo empregado possui um registro 
no CRM (Conselho Regional de Medicina), etc. Entretanto, o modelo nao re- 
presenta que combinacoes de atributos sao validas. Sera que um empregado 







pode possuir atributos CREA, CRM, data de expiragao da carteira de habilita- 
gao mas nao possuir o numero da carteira? 


tipo de 



data de 
carteira 


expirafao da 
de habilitafao 


( 0 . 1 ) 


CREA CEM numero da carteira 
(0,1) (0,1) de habilitafao (0,1) 


Figura 3.7: Atributos opcionais 


nome codlqo 



numero da data de CREA 

carteira de expirafao da 
habilitapao carteira de 
habilitapao 

Figura 3.8: Aumentando a fidelidade do modelo atraves de especializagoes 

O problema que ocorre no exemplo, e que o uso de atributos opcionais 
esconde as diferentes categorias de empregados e suas entidades. A realidade 
e modelada com maior fidelidade, caso a entidade EMPREGADO seja especi- 
alizada conforme mostra a figura 4.7. Neste modelo fica claro quais os atri- 
butos de cada um dos subconjuntos particulares de EMPREGADO. Assim, 
toda vez que aparecer um atributo opcional e aconselhavel verificar se a mo- 
delagem atraves de entidades especializadas nao e mais conveniente. 


3.2 3.2 Atributo multi-valorado 


EMPREGADO 

d) lanpament o pagament o (0,n) 
O dependents (0,n) 


O nome 


Figura 3.9: Usando atributos multi-valorados 



Figura 3.10: Substituindo atributos multi-valorados por entidades relaciona- 
das 

Atributos multi-valorados sao indesejaveis por duas razoes: 

□ Nos SGBD relacionais que seguem o padrao SQL/ 2, atributos multi-valo- 
rados nao possuem implementagao direta. Nao existe em um SGBD relati- 
onal uma construgao como os "arrays" de Pascal, nem como os grupos re- 
petidos de COBOL. Assim, caso esteja sendo projetada um banco de dados 
relational, e aconselhavel usar apenas atributos mono-valorados. 

□ Atributos multi-valorados podem induzir a um erro de modelagem, que e 
o de ocultar entidades e relacionamentos em atributos multi-valorados. A 
Figura 3.9 mostra um DER em que sao modelados empregados. Como 
atributos de EMPREGADO aparecem o nome do empregado, seus depen- 
dentes e os lanpamentos de pagamento que compoem seu contracheque. 
Entretanto, ao considerar a entidade EMPREGADO mais detalhadamente, 
observa-se que tanto dependentes, quanto os langamentos possuem pro- 
priedades particulares. Cada dependente possui um nome e uma data de 
nascimento. Ja um lancamento de pagamento possui um valor e um tipo 


de lancamento, sobre o qual tambem nos interessa manter informagSes, 
como o codigo do tipo e sua descrigao. Assim, o modelo correto para a re- 
alidade em questao e o apresentado na Figura 3.10. 

3.3 Verificacao do modelo 

Uma vez confeccionado, um modelo ER deve ser validado e verificado. A ve- 
rificagao e o controle de qualidade que procura garantir que o modelo usado 
para a constru^ao do banco de dados gerara um bom produto. Um modelo, 
para ser considerado bom, deve preencher uma serie de requisitos, como ser 
completo, ser correto e nao conter redundances. 

3.3.1 Modelo deve ser correto 

Um modelo esta correto quando nao contem erros de modelagem, isto e, 
quando os conceitos de modelagem ER sao corretamente empregados para 
modelar a realidade em questao. Pode-se distinguir entre dois tipos de erros, 
os erros sintdticos e os erros semanticos. Erros sintaticos ocorrem quando o mo- 
delo nao respeita as regras de constru^ao de um modelo ER. Exemplos de er- 
ros sintaticos sao o de associar atributos a atributos, o de associar relaciona- 
mentos a atributos, o de associar relacionamentos atraves de outros relacio- 
namentos ou de especializar relacionamentos ou atributos. Ja erros semanticos 
ocorrem quando o modelo, apesar de obedecer as regras de constru^ao de 
modelos ER (estar sintaticamente correto) reflete a realidade de forma incon- 
sistente. Alguns exemplos de erros semanticos praticados freqiientemente sao: 

□ Estabelecer associagdes incorretas. 

Um exemplo e associar a uma entidade um atributo que na realidade 
pertence a outra entidade. Por exemplo, em um modelo com entidades 
CLIENTE e FILIAL, associar a CLIENTE o nome da filial com o qual o cli- 
ente trabalha usualmente (nome de filial e um atributo de FILIAL). 

□ Usar uma entidade do modelo como atributo de outra entidade. 

Um exemplo seria ter, em um modelo, uma entidade BANCO e usar 
banco como atributo de uma outra entidade CLIENTE. Cada objeto da re- 
alidade modelada deve aparecer uma unica vez no modelo ER. 

□ Usar o numero incorreto de entidades em um relacionamento. 

Um exemplo e o de fundir em um unico relacionamento ternario dois 
relacionamentos binarios independentes. 

As regras de normalizagao de bases de dados relacionais apresentadas 
no proximo capitulo servem tambem para verificar a corregao de modelos ER. 

3.3.2 Modelo deve ser completo 

Um modelo completo deve fixar todas propriedades desejaveis do banco de 
dados. Isso obviamente somente pode ser verificado por alguem que conhece 
profundamente o sistema a ser implementado. Uma boa forma de verificar se 
o modelo e completo e verificar se todos os dados que devem ser obtidos do 
banco de dados estao presentes e se todas as transagSes de modificagao do 
banco de dados podem ser executadas sobre o modelo. 

Este requisito e aparentemente conflitante com a falta de poder de ex- 
pressao de modelos ER que foi citada acima. Quando dizemos que um mo- 


delo deve ser completo, estamos exigindo que todas propriedades expressaveis 
com modelos ER aparegam no modelo. 

3.3.3 Modelo deve ser livre de redundances 

Um modelo deve ser minirno, isto e nao deve conter conceitos redundantes. 

Um tipo de redundancia que pode aparecer e a de relacionamentos re- 
dundantes. Relacionamentos redundantes sao relacionamentos que sao resultado 
da combina^ao de outros relacionamentos entre as mesmas entidades. A 
Figura 3.11 apresenta um DER com relacionamentos redundantes. 



Figura 3.1 1: Relacionamentos redundantes 

Os relacionamentos desenhados em linhas densas no DER da Figura 3.11 
sao redundantes. O relacionamento LOCALIZAQAO-FABR entre MAQUINA e 
FABRICA e redundante. Um relacionamento e redundante, quando e possivel 
elimina-lo do diagrama ER, sem que haja perda de informagSes no banco de 
dados. No caso do relacionamento LOCALIZAQAO-FABR, a associagao entre 
entidades por ele expressa ja esta contida nos relacionamentos LOCALIZAQAO- 
DEPT e F-D. Em outros termos, como o banco de dados informa em que de- 
partamento uma maquina esta localizada e em que fabrica o departamento 
esta localizado, ela informa por conseqiiencia em que fabrica uma maquina 
esta localizada. Seguindo raciocinio analogo e facil verificar que o relaciona- 
mento ATUAQAO, entre FABRICA e SINDICATO e redundante, pois a informa- 
gao nele contida e derivada da informagao fornecida pelos relacionamentos 
ASSOCIAgAO, D-E e F-D. 

Um outro tipo de redundancia que pode aparecer em modelos ER e a de 
atributos redundantes. Atributos redundantes sao atributos derivaveis a partir 
da execugao de procedimentos de busca de dados e/ou calculos sobre o banco 
de dados. 


c6d\go 



n de empregados codigo dodepartament-o 


Figura 3.12: Atributos redundantes 

A Figura 3.12 apresenta um DER que content dois atributos redundantes 
(n e de empregados e codigo do departamento). O atributo codigo do departamento 
e redundante pois pode ser obtido atraves do acesso a entidade 
DEPARTAMENTO associada a entidade EMPREGADO atraves do relaciona- 
mento de LOTAQAO 5 . Ja o atributo n e de empregados e redundante pois pode 
ser obtido atraves de um processo de contagem sobre o relacionamento 
LOTAQAO. 

Construgbes redundantes devem ser omitidas do modelo ER. Como o 
diagrama ER nao distingue construgbes derivadas das demais construgbes, o 
projetista do banco de dados poderia ser levado a implementa-las gerando 
redundancia nao controlada de dados. Redundancia nao controlada de dados 
em um banco de dados e indesejavel por diversas razoes. Construgbes redun- 
dantes normalmente implicam desperdicio de espago de armazenamento. 
Construgbes redundantes podem resultar em informagoes incorretas, caso nao 
sejam alteradas em sincronia com as informagoes das quais sao derivadas. 
Observe que isso nao significa que redundancia controlada de dados (redun- 
dancia de dados da qual programas e usuarios tern conhecimento) deva tam- 
bem ser necessariamente evitada. As vezes, construgbes redundantes em um 
banco de dados podem servir para aumentar a performance de operagoes de 
busca de informagoes no banco de dados, mas nem por isso devem aparecer 
no modelo conceitual do banco de dados. 

3.3.4 Modelo deve refletir o aspecto temporal 

Usualmente, ao iniciar a modelagem ER, a preocupagao e obter um modelo 
que descreva os estados validos e corretos do banco de dados. O primeiro 
modelo tende a refletir um estado momentaneo do banco de dados. Entre- 
tanto, e necessario lembrar que assim como informagoes sao incluidas no 
banco de dados, elas tambem podem ter que ser eliminadas do banco de da- 
dos. Um banco de dados nao pode crescer indefinidamente. Informagoes ul- 
trapassadas ou desnecessarias podem ser eliminadas. Portanto, e necessario 
considerar o aspecto temporal na modelagem de dados. Nao ha regras gerais de 


5para o leitor afeito a terminologia de bancos de dados relacionais, codigo do 
departamento e uma assim chamada cliave estmngeira. Este atributo e usado em um banco de 
dados relacional, como veremos nos proximos capitulos, para implementar o relacionamento 
LOT AC AO. Como no modelo ER ainda nao entramos em detalhes de implementacao com 
SGBD relacional, o atributo deve ser omitido. 


como proceder neste caso, mas e possivel identificar alguns padroes que re- 
petem-se freqiientemente na pratica. 

3.3.4.1 Atributos cujos valores modificam ao longo do tempo 

Alguns atributos de uma entidade, normalmente aqueles que nao sao identifi- 
cadores da entidade, podem ter seus valores alterados ao longo do tempo (por 
exemplo, o enderego de um cliente pode ser modificado). Algumas vezes, por 
questoes de necessidades futuras de informagSes, ou ate mesmo por questoes 
legais, o banco de dados deve manter um registro historico das informagSes. 
Um exemplo e o valor do salario de um empregado. Num sistema de paga- 
mento, nao interessa saber apenas o estado atual, mas tambem o salario du- 
rante os ultimos meses, por exemplo, para emitir uma declaragao anual de 
rendimentos de cada empregado. Assim, salario nao pode ser modelado como 
um atributo, mas sim como uma entidade. A figura 4.12 apresenta as duas al- 
ternativas de modelagem. 



(a) (b) 

Banco de dados contem Banco de dados contem 
apenas o salario a historia dos salarios 

Figura 3.13: Modelando a dimensao temporal de atributos 

3.3.4.2 Relacionamentos que modificam ao longo do tempo 

Assim como atributos podem ter seus valores modificados ao longo do 
tempo, tambem relacionamentos podem ser modificados e tambem neste caso 
pode ser requerido que o banco de dados mantenha um registro historico das 
alteragSes. 

Em geral, relacionamentos que, ao considerar apenas o estado atual do 
banco de dados, possuem cardinalidade 1:1 ou l:n sao transformados em car- 
dinalidade n:n, quando e considerada a historia das alteragSes de relaciona- 
mento. 

Para exemplificar, consideramos o relacionamento ALOCAQAO da Figura 
3.14(a). Este relacionamento possui cardinalidade 1:1, ou seja, cada empre- 
gado esta alocado a no maximo uma mesa e cada mesa tern a ela alocado no 
maximo um empregado. Este modelo esta correto caso deseje-se armazenar 
no banco de dados apenas a alocagao atual de cada mesa. Entretanto, caso de- 
seje-se armazenar tambem a historia das alocagoes, isto e, que empregados 


estiveram alocados a que mesas ao longo do tempo, e necessario modificar o 
modelo (Figura 3.14 (b)). O relacionamento passa a ter cardinalidade n:n, ja 
que, ao longo do tempo um empregado pode ter sido alocado a diversas me- 
sas e uma mesa pode ter tido a ela alocados muitos empregados. Como um 
mesmo empregado pode ter sido alocado a mesma mesa multiplas vezes, 
torna-se necessario um atributo identificador do relacionamento, afim de dis- 
tinguir uma alocagao de um determinado empregado a uma mesa, das demais 
alocagSes deste empregado a mesma mesa. Com isso surge o atributo identifi- 
cador data. 



(a) (b) 

Base de dados contem Base de dados contem 

apenas a aloca§ao atual a historia das aloca§des 


Figura 3. 1 4: Modelando a dimensao temporal de relacionamentos 1 : 1 

A Figura 3.15 apresenta uma situagao semelhante, agora considerando 
um relacionamento de cardinalidade l:n. Se quisermos considerar a historia 
das lotagoes de empregados ao longo do tempo, e necessario transformar o 
relacionamento para a cardinalidade n:n, ja que ao longo do tempo um em- 
pregado pode ter atuado em diferentes departamentos. Neste caso, pode 
ocorrer tambem que atributos da entidade EMPREGADO migrem para o rela- 
cionamento. No caso do exemplo, isto ocorre com o atributo n e documento de 
lotagao. Este atributo, que, na primeira versao do modelo, aparece na entidade 
EMPREGADO, migra, na nova versao, para o relacionamento, ja que na nova 
versao um empregado pode estar relacionado com multiplos departamentos. 

A Figura 3.16 apresenta mais um caso de consideragao de historia de 
relacionamentos. Neste caso, trata-se de um relacionamento de cardinalidade 
n:n. Modela-se a inscrigao de participantes nos cursos oferecidos por uma 
empresa de treinamento. Na primeira versao, considera-se apenas os cursos 
nos quais uma pessoa esta inscrita em um determinado instante no tempo. Na 
segunda versao, considera-se todas as inscricoes, inclusive as do passado. A 
modificagao de uma versao para a outra consta da transformagao do atributo 
data em atributo identificador. Isto ocorre porque, na segunda versao, um 
participante pode aparecer relacionado multiplas vezes a um determinado 
curso (caso ele tenha se inscrito multiplas vezes no curso). O atributo passa a 
distinguir uma inscrigao de uma pessoa em um curso, das demais inscricoes 
desta pessoa no mesmo curso. 


: n° documento 
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no me 
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Base de dados contem 
apenas a lota§ao atual 


Base de dados contem 
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Figura 3. 1 5: Modelando a dimensao temporal de relacionamentos 1 :n 


(a) 



(b) 


Base de dados contem 
apenas a inscri§ao atual 


Base de dados contem 
a historia das inscri§oes 


Figura 3.16: Modelando a dimensao temporal de relacionamentos n:n 


3.3.4.3 Consultas a dados referentes ao passado 

Muitas vezes, para evitar o crescimento desmedido do banco de dados, in- 
formacoes referentes ao passado sao eliminadas. Entretanto, estas informa- 
coes podem ser necessarias no futuro, por exemplo, por motivos legais, para 
realizacao de auditorias ou para tomada de decisoes. Portanto, e necessario 
planejar desde a modelagem, por quanto tempo as informagSes ficarao arma- 
zenadas no banco de dados. Caso informagSes antigas fiquem no banco de 
dados, podem ser necessaries atributos para indicar o status da informacao, se 
atual ou antiga. 

□ Planejar o arquivamento de informagdes antigas 

Para as informacoes que serao retiradas do banco de dados e armazena- 
das em arquivos convencionais, e necessario fazer um planejamento de 
como estas informacoes serao acessadas no futuro, caso venham a ser ne- 
cessarias. Uma solucao que poderia ser considerada, e a de reincluir as in- 
formacoes no banco de dados, quando elas forem necessarias no futuro. 
Isso permite que, para buscar as informacoes passadas, sejam usados os 










mesmos procedimentos que sao usados para acessar as informagoes atu- 
ais. Entretanto, e necessario considerar que as informagSes em um banco 
de dados estao normalmente relacionadas a outras. Caso as ocorrencias de 
entidade que se deseja devolver a base de dados estejam relacionadas a 
outras ocorrencias, e necessario que estas estejam presentes. Se elas tam- 
bem tiverem sido excluidas, deverao ser igualmente devolvidas a base de 
dados. Essa inclusao pode ser propagada em cascata para outras entida- 
des. 

□ Planejar informagdes estatisticas 

Em alguns casos, informagdes antigas sao necessarias apenas para tomada 
de decisoes. Neste caso, muitas vezes deseja-se apenas dados resultantes 
de calculos ou estatisticas sobre as informagoes, como totais, contagens, 
medias,.... Assim pode ser conveniente manter no banco de dados estas 
informagSes compiladas e eliminar as informagSes usadas na compilagao. 

3.3.5 Entidade isolada e entidade sem atributos 

Uma entidade isolada e uma entidade que nao apresenta nenhum relaciona- 
mento com outras entidades. Em principio, entidades isoladas nao estao in- 
corretas. Uma entidade que muitas vezes aparece isolada e aquela que modela 
a organizagao na qual o sistema implementado pelo BD esta embutida. To- 
memos como exemplo o BD de uma universidade que aparece na Figura 2.13. 
A entidade UNIVERSIDADE pode ser necessaria, caso se deseje manter no BD 
alguns atributos da universidade. Mesmo assim, o modelo nao deveria conter 
o relacionamento desta entidade com outras, como ALU NO ou CURSO. Como 
o BD modela uma unica universidade, nao e necessario informar no BD em 
que universidade o aluno esta inscrito ou a qual universidade o curso per- 
tence. 

Mesmo assim, a ocorrencia de entidades isoladas em modelos na pratica 
e rara e por isso deve ser investigada em detalhe, para verificar se nao foram 
esquecidos relacionamentos. 

Uma outra situagao que nao esta incorreta, mas deve ser investigada, e a 
de uma entidades sem atributos. 

3.4 Estabelecendo padroes 

Modelos de dados sao usados para comunicagao entre as pessoas da organi- 
zagao (usuarios, analistas, programadores,...) e ate mesmo para a comunica- 
gao com programas (ferramentas CASE, geradores de codigo,...). Assim, ao 
usar modelagem de dados, e necessario estabelecer padroes de confecgao de 
modelos. Infelizmente, na pratica e na literatura nao aparece uma versao ape- 
nas de modelo ER, mas muitas, que distinguem-se umas das outras nao so na 
representagao grafica, isto e em sua sintaxe, mas tambem na semantica. Nesta 
segao discutimos algumas variantes da abordagem ER e como garantir a utili- 
zagao de uma variante escolhida. 

3.4.1 Variantes de modelos ER 

Quando de seu surgimento na literatura, a abordagem ER nao era ainda su- 
portada por ferramentas em computador de edigao e manipulagao, como as 


ferramentas CASE hoje existentes. Com isso, cada autor de livro sobre o as- 
sunto, bem como cada usuario da abordagem tinha total liberdade para esco- 
lher uma representagao grafica e ate mesmo uma semantica para a aborda- 
gem. A consequencia e que hoje observa-se uma grande variedade de aborda- 
gens que levam o tftulo de entidade-relacionamento. Ate este ponto do livro, 
apresentamos a abordagem ER na forma que aparece mais frequentemente na 
literatura e que e muitas vezes usada na pratica. Essa notagao e as vezes refe- 
rida como notagao tipo "Chen" pois, com algumas extensoes, segue a notagao 
proposta por Peter Chen em seu primeiro artigo sobre a abordagem. 

Alem desta notagao duas famllias de notagSes tern importancia, a nota- 
gao Engenharia de Informagoes e a notagao MERISE. 

3.4.1. 1 Notagao Engenharia de Informagoes 

A Engenharia de Informagoes e uma metodologia de desenvolvimento de 
sistemas de informagao proposta no inicio da decada de 80 por Martin e 
Finkelstein. Essa metodologia tern uma importancia consideravel na pratica, 
comprovada pela existencia de ferramentas CASE que a suportam. A caracte- 
ristica mais importante desta metodologia e seu embasamento na modelagem 
de dados. A organizagao e vista fundamentalmente atraves do modelo de da- 
dos. 



Notagao para cardinalidade maxima e minima: 

| Cardinalidade (minima, maxima) 1 

o Cardinalidade minima 0 

— Cardinalidade maxima n 

Figura 3.17: Notagao Engenharia de Informagoes 

Para a Engenharia de Informagoes, foi definida uma notagao especial de 
diagramas ER, conhecida como notagao Engenharia de Informagoes, ou tam- 
bem notagao James Martin. 

A Figura 3.17 apresenta um exemplo de um DER na notagao Chen ate 
aqui empregada e o correspondente DER na notagao Engenharia de Informa- 
goes. As diferengas principals sao as seguintes: 


□ Na notagao Engenharia de InformagSes, relacionamentos sao represen- 
tados apenas por uma linha que liga os simbolos representativos das en- 
tidades associadas. Isso tem as seguintes conseqiiencias: 

• A notagao admite apenas relacionamentos binarios, ja que uma linha 
apenas conecta duas entidades. Relacionamentos temarios ou de grau 
maior sao modelados atraves de uma entidade associada atraves de 
relacionamentos binarios a cada uma das entidades que participam 
do relacionamento ternario. 

• Atributos aparecem exclusivamente em entidades. Com isso, objetos 
que seriam modelados como relacionamentos n:n na notagao de Chen 
tendem a ser modelados como entidades na notagao de Engenharia de 
Informagoes. 

□ A denominagao de um relacionamento e escrita na forma de verb os em 
ambas diregSes de leitura (DEPARTAMENTO tem lotado EMPREGADO, 
EMPREGADO esta lotado em DEPARTAMENTO). 

□ A notagao para cardinalidade maxima e minima e grafica. O simbolo 
mais proximo do retangulo representativo da entidade corresponde a 
cardinalidade maxima, o mais distante a cardinalidade minima. 

□ A generalizagao/especializagao e chamada de subconjunto (subtipo) de 
entidades e e representada atraves do aninhamento dos simbolos de en- 
tidade conforme mostra a Figura 3.18. 

A Figura 3.18 apresenta um exemplo mais abrangente representado com 
a notagao da Engenharia de InformagSes (trata-se do mesmo modelo ER apre- 
sentado na Figura 2.37) 



Figura 3.18: Modelo ER da Figura 2.37 na notagao de Engenharia de Informa- 
goes 

3.4.1. 2 Notagao MERISE 

MERISE e a metodologia de desenvolvimento de sistemas muito popular na 
Franga. Uma etapa desta metodologia, e a de modelagem de dados. Na mo- 
delagem de dados, MERISE adota diagramas ER, com uma notagao um pouco 


diferente da usual. Em prindpio, esta notagao nao seria de maior importancia 
para o leitor deste texto. Entretanto, ha um grupo padronizagao na ISO ("In- 
ternational Standards Organization") que esta estudando a padronizagao de 
notagSes de DER. Relatorios preliminares deste grupo indicam que uma das 
tecnicas que pode vir a ser adotada e a empregada em MERISE. 



Figura 3.19: Notagao Chen e correspondente notagao MERISE 

A Figura 3.19 apresenta um DER na notagao Chen e o DER correspon- 
dente na notagao MERISE. Como se observa, alem da modificagao cosmetica 
de representar o relacionamento por uma elipse, ao inves de um losango, a 
posigao em que sao indicadas as cardinalidades minima e maxima mudou. O 
motivo e que a interpretagao dada a cardinalidade em MERISE e diferente da 
usual. Na interpretagao usual de cardinalidade, ela indica quantas ocorrencias 
de entidade (no minimo e no maximo) podem estar associadas a uma ocor- 
rencia de determinada entidade. Esta interpretagao e a chamada de semantica 
associativa. Em MERISE usa-se a semantica participativa. Nesta a cardinalidade 
indica quantas vezes uma ocorrencia de entidade participa de um relaciona- 
mento. Exemplificando, na figura acima na notagao Chen, a cardinalidade 
(1,1) representa o fato de um empregado estar vinculado a no minimo um e 
no maximo um departamento. Ja no diagrama em MERISE, a a notacao 1,1 
indica que uma ocorrencia da entidade EMPREGADO participa no minimo 
uma e no maximo uma vez do relacionamento LOTACAO. 

3.4.2 Uso de ferramentas de modelagem 

Na pratica, nao e aceitavel que o diagrama ER seja confeccionado manual- 
mente. A criagao de um DER a mao e muito trabalhosa, pois, durante o pro- 
cesso de modelagem, as revisoes sao freqiientes. Alem disso, dificilmente dia- 
gramas feitos a mao serao atualizados, quando de alteragoes do modelo du- 
rante a sua vida util. Portanto, e recomendavel que desde o inicio da confec- 
gao do DER, seja usada uma ferramenta em computador para apoio a mode- 
lagem. Podem ser consideradas duas alternativas: 

3.4.2.1 Uso de uma ferramenta CASE 

O software ideal para acompanhar o projeto de um banco de dados e uma fer- 
ramenta CASE (CASE - "computer aided software engineering"). Uma ferra- 
menta CASE pode apoiar o desenvolvimento de um banco de dados tanto a 


nfvel de modelagem quanto a nfvel de projeto do banco de dados. Do ponto 
de vista da modelagem o minimo que se deve exigir de uma ferramenta CASE 
e: 

□ Capacidade de edigao diagramdtica 

A ferramenta CASE deve oferecer uma interface grafica poderosa e facil 
de usar, que permita construir o DER diretamente no computador. A 
modificacao do DER (inclusao/ eliminacao/ movimenta^ao) de simbolos 
deve ser simplificada. 

□ Diciondrio de dados 

A ferramenta deve possuir um diciondrio de dados, isto e, uma pequeno 
banco de dados, onde toda descrigao do DER esta armazenada. 

□ Integragdo entre o diagrama ER e o diciondrio de dados 

O dicionario de dados deve ser integrado ao DER. A partir do DER deve 
ser possivel visualizar e editar as entradas do dicionario de dados cor- 
respondentes a elementos selecionados do DER. 

3.4.2.2 Uso de programas de proposito geral 

Em organizagSes com pequeno orcamcnto para a Informatica, pode ser dificil 
obter os recursos necessarios a aquisicao de uma ferramenta CASE. Neste 
caso, pode-se usar programas de proposito geral para editar o DER e montar 
o dicionario de dados: 

□ Edigao do DER 

Para editar o DER pode-se utilizar um programa de desenho de propo- 
sito geral. Ha programas de desenho que trabalham com os conceitos de 
nodo e de arco. Nestes programas, quando o usuario mover um nodo do 
diagrama, todos arcos ligados a este nodo sao tambem movimentados. 
Este tipo de programas sao particularmente adequados para edigao de 
diagramas ER. 

□ Diciondrio de dados 

Para construir o dicionario de dados pode-se utilizar um processador de 
textos, uma planilha eletronica ou um banco de dados (esta e a melhor 
opgao). A escolha provavelmente ira recair sobre o programa que for 
mais conhecido e dominado na organizacao em questao. 

3.5 Estrategias de modelagem 

O processo de construcao de um modelo e um processo incremental, isto e, 
um modelo de um sistema nao e construido em um unico passo, mas em 
muitos passos pequenos, muitas pequenas transformacSes do modelo inicial 
ate o modelo completo. Gradativamente, o modelo vai sendo enriquecido 
com novos conceitos e estes vao sendo ligados aos existentes ou os existentes 
vao sendo aperfeicoados. Uma estrategia de modelagem ER e uma seqiiencia 
de passos (uma "receita-de-bolo") de transformagao de modelos. Estudando o 
processo de construcao de modelos ER, diferentes autores propuseram dife- 
rentes estrategias, que apresentamos abaixo. 

Na pratica, observa-se que nenhuma das estrategias propostas na lite- 
ratura e universalmente aceita. Normalmente, e aplicada uma combinacao das 



diversas estrategias de modelagem. Isso e compreensivel, se considerarmos 
que o processo de modelagem e um processo de aprendizagem. Quando 
construimos o modelo de um sistema, estamos aprendendo fatos sobre aquele 
sistema. A seqiiencia de ideias que se tern durante um processo de aprendiza- 
gem e dificilmente controlavel por uma estrategia. 

Para definir qual a estrategia a usar na construgao de um modelo ER, 
deve-se identificar qual a fonte de informagSes principal para o processo de 
modelagem. Sao duas as fontes de informagao que iremos considerar: descri- 
bes de dados existentes e o conhecimento que pessoas possuem sobre o sis- 
tema. 

3.5.1 Partindo de describes de dados existentes 

Uma opgao de fonte de informagSes para o processo de modelagem de dados 
sao describes de dados ja existentes. 

Exemplificando, esta situagao ocorre, quando deseja-se obter um modelo 
de dados para um sistema em computador existente. Neste caso usa-se como 
describe dos dados as describes dos arquivos utilizados pelo sistema em 
computador. Este caso e conhecido por engenharia reversa, pois objetiva obter 
uma especificacao (o modelo) a partir de um produto existente (o sistema em 
computador). 

Outro exemplo do uso de describes de dados ja existentes e quando sao 
utilizadas describes dos documentos (pastas, fichas, documentos fiscais,...) 
usados em um sistema nao automatizado. 

Para estes casos, a estrategia mais adequada e a estrategia "bottom-up" 
(de baixo para cima). Esta estrategia consta de partir de conceitos mais deta- 
lhados ("embaixo" em termos de niveis de abstracao) e abstrair gradativa- 
mente. O processo de modelagem inicia com a identi fi cacao de atributos (con- 
ceitos mais detalhados). A partir dai, os atributos sao agregados em entidades 
e as entidades sao relacionadas e generalizadas. Essa forma de trabalhar e 
adequada quando ja disp5e-se dos atributos. Normalmente, isso ocorre, 
quando ja possui-se uma definicao dos dados que deverao estar armazenados 
no banco de dados. Iremos tratar essa estrategia em detalhe em um capitulo a 
parte. 

3.5.2 Partindo do conhecimento de pessoas 

A outra opcao e partir do conhecimento que pessoas possuem sobre o sistema 
sendo modelado. Este e o caso, quando novos sistemas, para os quais nao 
existem describes de dados, estao sendo concebidos. Para este caso, podem 
ser aplicadas duas estrategias, a " top-down " e a "inside-out". 

3.5.2.1 Estrategia “top-down” 

Esta estrategia consta de partir de conceitos mais abstratos ("de cima") e ir 
gradativamente refinando estes conceitos em conceitos mais detalhados. Ou 
seja, segue-se o caminho inverso da estrategia "bottom-up". Aqui o processo 
de modelagem inicia com a identificagao de entidades genericas (conceitos 
mais abstratos). A partir dai, sao definidos os atributos das entidades, seus 



relacionamentos, os atributos dos relacionamentos, e as especializaqSes das 
entidades. 

Uma seqiiencia de passos para obter um modelo usando a estrategia 
"top-down" e a mostrada abaixo: 

1. Modelagem superficial - Nesta primeira etapa, e construfdo um DER pouco 
detalhado (faltando dommios dos atributos e cardinalidades mfnimas de rela- 
cionamentos) na seguinte sequencia: 

a) Enumeracao das entidades. 

b) Identificacao dos relacionamentos e hierarquias de generaliza- 
qao/especializaqao entre as entidades. 

Para cada relacionamento identifica-se a cardinalidade maxima. 

c) Detcrminacao dos atributos de entidades e relacionamentos. 

d) Detcrminacao dos identificadores de entidades e relacionamen- 
tos. 

e) O banco de dados e verificado quanto ao aspecto temporal. 

2. Modelagem detalhada - Nesta etapa, completa-se o modelo com os doml- 
nios dos atributos e cardinalidades rmnimas dos relacionamentos: 

a) Adiciona-se os dommios dos atributos. 

b) Define-se as cardinalidades rmnimas dos relacionamentos. E 
preferfvel deixar estas cardinalidades por ultimo, ja que exigem 
conhecimento bem mais detalhado sobre o sistema, inclusive 
sobre as transaqSes. 

c) Define-se as demais restriqbes de integridade que nao podem ser 
representadas pelo DER. 

3. Validagao do modelo 

a) Procura-se construcoes redundantes ou derivaveis a partir de 
outras no modelo. 

b) Valida-se o modelo com o usuario. 

Em qualquer destes passos e possfvel retornar a passos anteriores. Exemplifi- 
cando, durante a identi fi cacao de atributos e possfvel que sejam identificadas 
novas entidades, o que faria com que o processo retornasse ao primeiro passo. 

Z.5.2.2 Estrategia “inside-out” 

A estrategia "inside-out" (de dentro para fora) consta de partir de conceitos 
considerados mais importantes (centrais, parte-se "de dentro") e ir gradati- 
vamente adicionando conceitos perifericos a eles relacionados (ir "para fora"). 
Aqui, o processo inicia com a identificacao de uma entidade particularmente 
importante no modelo e que, sup5e-se, estara relacionada a muitos outras en- 
tidades. A partir daf, sao procurados atributos, entidades relacionadas, gene- 
ralizaqSes e especializacoes da entidade em foco, e assim recursivamente ate 
obter-se o modelo completo. A denominaqao da estrategia provem da ideia de 
que entidades importantes em um modelo e relacionadas a muitos outras sao 
usualmente desenhadas no centro do diagrama, afim de evitar cruzamento de 
linhas. Um exemplo da aplicacao desta estrategia e mostrado na Figura 3.20. 




Figura 3.20: Aplicagao da estrategia “de dentro para fora” 

Na Figura 3.20, esta mostrada a modelagem de uma parte de um sistema 
de recursos humanos. As linhas em tons de cinza indicam os passos da cons- 
trugao do modelo. No caso, considerou-se como conceito central e ponto de 
partida da modelagem a entidade EMPREGADO. Apos, procurou-se entidades 
relacionadas a EMPREGADO, tendo sido identificada a entidade 
DEPARTAMENTO. No proximo passo, foram identificados os atributos e espe- 
cializagSes de EMPREGADO e finalmente foram identificados os atributos e as 
entidades relacionados as especializagoes de EMPREGADO. 

Os passos que ocorrem no processo "inside-out" sao os mesmos que 
ocorrem no processo "top-down" ocorrendo, entretanto, uma iteragao muito 
maior entre os passos l.a, l.b e l.c. 

Exercicios 

Exercfcio 3.1: A Figura 3.21 apresenta um relacionamento que associa um 
produto de uma industria com seus componentes (em ingles, "bill-of-materi- 
als"). Cada produto pode possuir diversos componentes e cada componente 
pode aparecer dentro de diversos produtos. Assim trata-se de um relaciona- 
mento do tipo n:n. Uma restrigao que deve ser imposta sobre o banco de da- 
dos em questao e a de que um produto nao pode aparecer na lista de seus 
componentes. Pergunta-se: 

a) O modelo apresentado na figura contem esta restricao? 


b) Caso negativo, e possivel alterar o modelo em questao para incluir esta 
restricao, se considerarmos que o nivel de profundidade da hierarquia de 
composi^ao de cada produto nao excede tres (tem-se apenas produtos 
prontos, produtos semi-acabados e materias-primas)? Caso afirmativo, 
apresente a solugao. 

c) E possivel estender a solucao do quesito anterior para uma hierarquia nao 
limitada de niveis de composigao? 


PRODUTO 


composto components 



Figura 3.21: Composigao de produtos 

Exercicio 3.2:Deseja-se modelar os clientes de uma organizacao. Cada cliente 
possui um identificador, um nome, um cndereco e um pais. Discuta os pros e 
contras das duas alternativas de modelagem de pais: 

a) Como atributo da entidade cliente 

b) Como entidade relacionada a cliente. 

Exercicio 3.3: A Figura 3.22 apresenta uma entidade e respectivos atributos, 
muitos deles opcionais e um multi-valorado. Considere que ha dois tipos de 
clientes, pessoas fisicas e pessoas juridicas. Pessoas fisicas possuem codigo, 
CIC, nome, sexo (opcional), data de nascimento (opcional) e telefones (opcio- 
nais). Pessoas juridicas possuem codigo, CGC, razao social e telefones (opcio- 
nais). Apresente um diagrama ER que modele mais precisamente esta reali- 
dade. Explique no que seu diagrama e mais preciso que o mostrado na fi- 
gura 4.21. 


nome (0,1) sexo (0,1) 

9 ? 9 


CLIENTE 

3 5 5 


-0 


data de nascimento 
telefone (0,n) 


{ 0 , 1) 


CIC CGC razao social 

( 0 , 1 ) ( 0 , 1 ) ( 0 , 1 ) 


Figura 3.22: Cliente com atributos 

Exercicio 3.4: Transforme o modelo ER resultante do exercicio anterior da 
notapao Chen para a notapao da Engenharia de Informacoes. 

Exercicio 3.5: Estudo de caso - Administradora de imoveis 





Construa um diagrama ER (apenas entidades e relacionamentos com cardina- 
lidades maximas) para a administradora de imoveis descrita abaixo. 

A administradora trabalha tanto com administrate) de condominios, 
quanto com a administracao de alugueis. 

Uma entrevista com o gerente da administradora resultou nas seguintes 
informacoes: 

a) A administradora administra condominios formados por unidades con- 
dominiais. 

b) Cada unidade condominial e de propriedade de uma ou mais pessoas. 
Uma pessoa pode possuir diversas unidades. 

c) Cada unidade pode estar alugada para no maximo uma pessoa. Uma pes- 
soa pode alugar diversas unidades. 

Exercicio 3.6: Estudo de caso - Locadora de videos 

(adaptado do material de um curso de modelagem de dados da Oracle) 

Uma pequena locadora de videos possui ao redor de 2.000 fitas de video, cujo 
emprestimo deve ser controlado. 

Cada fita possui um numero. Para cada filme, e necessario saber seu ti- 
tulo e sua categoria (comedia, drama, aventura, ...). Cada filme recebe um 
identificador proprio. Para cada fita e controlado que filme ela contem. Para 
cada filme ha pelo menos uma fita, e cada fita contem somente um filme. Al- 
guns poucos filmes necessitam duas fitas. 

Os clientes podem desejar encontrar os filmes estrelados pelo seu ator 
predileto. Por isso, e necessario manter a informacao dos atores que estrelam 
em cada filme. Nem todo filme possui estrelas. Para cada ator os clientes as 
vezes desejam saber o nome real, bem como a data de nascimento. 

A locadora possui muitos clientes cadastrados. Somente clientes cadas- 
trados podem alugar fitas. Para cada cliente e necessario saber seu prenome e 
seu sobrenome, seu telefone e seu endereco. Alem disso, cada cliente recebe 
um numero de associado. 

Finalmente, desejamos saber que fitas cada cliente tern emprestadas. Um 
cliente pode ter varias fitas em um instante no tempo. Nao sao mantidos re- 
gistros historicos de alugueis. 

Exercicio 3.7: Estudo de caso - Sistema de reserva de passagens aereas 

O objetivo do trabalho e projetar um sistema de reservas para uma companhia 
de aviagao. O sistema contara com um banco de dados central, que sera aces- 
sado por aplicacoes clientes, rodando tanto dentro da propria companhia, 
quanto fora dela. 

A transacao central do sistema e a reserva. Uma reserva e identificada 
por um codigo gerado pelo sistema em computador. A reserva e feita para um 
unico passageiro, do qual se conhece apenas o nome. A reserva compreende 
um conjunto de trechos de voos, que acontecerao em determinada data/hora. 
Para cada trecho, a reserva e feita em uma classe (economica, executiva, etc.). 

Um voo e identificado por um codigo e possui uma origem e um des- 
tino. Por exemplo, o voo 595 sai de Porto Alegre com destino a Sao Paulo. Um 
voo e composto de varios trechos, correspondendo as escalas intermediaries 



do voo. Por exemplo, o voo 595 e composto de dois trechos, um de Porto Ale- 
gre a Londrina, o outro de Londrina a Sao Paulo. Cabe salientar que ha cida- 
des que sao servidas por varios aeroportos. Por isso, e importante informar ao 
passageiro que faz a reserva, qual e o aeroporto no qual o voo passa. 

As vezes os clientes, ao fazer a reserva querem saber qual e o tipo de ae- 
ronave que sera utilizada em determinado trecho de voo. Alguns poucos 
voos, principalmente internacionais, tem troca de aeronave em determinadas 
escalas. 

Nem todos voos operam em todos dias de semana. Inclusive, certos voos 
tem pequenas mudancas de horario em certos dias da semana. 

Cada reserva possui um prazo de validade. Caso os bilhetes nao tenham 
sido emitidos, ate esgotar-se o prazo da reserva, a mesma e cancelada. Reser- 
vas podem ser prorrogadas. 

Como o "check-in" de todos os voos esta informatizado, a companhia 
possibilita a reserva de assento para o passageiro. Reservas de assento podem 
ser feitas com ate tres meses de antecedencia 

Alem de efetivar reservas, o sistema deve servir para varios tipos de 
consultas que os clientes podem querer fazer: 

a) possibilidades de viagem de uma cidade ou de um aeroporto para outro 

b) o mesmo, mas restrito a determinados dias da semana 

c) horarios de chegada ou de saida em determinados voos 

d) disponibilidade de vagas em um trecho de voo 

e) disponibilidade de determinados assentos em um trecho de voo. 

Exercicio 3.8: Estudo de caso - Sistema para locadora de veiculos 

O objetivo deste estudo de caso e construir um modelo ER para o BD de uma 
empresa de locagao de veiculos. A empresa em questao aluga automoveis, 
camionetas de passageiros e camionetas de carga. 

Ela atende a dois mercados, o das pessoas fisicas e o das pessoas juridi- 
cas. Para acelerar o atendimento, e importante conhecer os dados de clientes 
que ja tenham usado a locadora no passado. Para cada pessoa fisica e necessa- 
rio conhecer seu nome, sexo, data de nascimento, enderego e CIC. Ja para as 
pessoas juridicas e necessario conhecer seu nome, CGC, inscri^ao estadual e 
enderego. Os clientes sao identificados por um codigo interno a locadora. 

A empresa tem uma grande rede de filiais, espalhada pelo sul do pais. 
Em um momento no tempo, um veiculo encontra-se sob responsabilidade de 
uma filial. Entretanto, como veiculos podem ser alugados para viagens em 
um sentido somente, eles podem mudar de filial. Um veiculo e identificado 
pela sua placa. Alem disso, e necessario conhecer o numero do chassis, o nu- 
mero do motor, o tipo de veiculo e a cor de cada veiculo. 

O sistema em computador devera registrar: 

a) os veiculos disponiveis em determinada filial na data corrente, 

b) as reservas para veiculos em uma filial, com previsao de que veiculos esta- 
rao disponiveis em uma data futura, 

c) os veiculos presentemente alugados pela filial, o ponto de entrega (caso 
seja diferente do de locacao) e data de entrega prevista. 



Os veiculos sao classificados por uma tabela de tipos. Por exemplo, P3 
corresponde a automoveis pequenos, de quatro portas e com ar-condicionado 
(Uno, Palio, etc.) e G4 a grandes automoveis de luxo (Omega ou similar). As 
reservas nao sao feitas para uma marca ou modelo de veiculo, mas para um 
tipo de veiculo. 

Para tipos de automoveis, os clientes desejam saber o tamanho, classifi- 
cado em pequeno, medio e grande, o numero de passageiros, o numero de 
portas, bem como se possui os seguintes acessorios: ar-condicionado, radio, 
toca-fitas, CD, diregao hidraulica e cambio automatico. Para tipos de camio- 
netas de passageiros, as informagSes sao as mesmas que para automoveis. Ja 
para tipos de camionetas de carga, as informacoes acima nao sao relevantes. 
Neste caso, os clientes desejam saber a capacidade de carga da camioneta. 

Para cada tipo de veiculo, ha um determinado numero de horas necessa- 
rio para limpeza e revisao de entrega, entre uma reserva e outra. 

Alem disso, o sistema deve programar as revisoes dos veiculos, impe- 
dindo que sejam reservados quando ha revisoes pendentes. Esta programacao 
e feita com base em um conjunto de parametros que sao a quilometragem 
atual do veiculo, a quilometragem media diaria de um veiculo do tipo, bem 
como em uma tabela de revisSes do tipo de veiculo. 

A seguradora que segura os veiculos, exige que, para cada veiculo alu- 
gado, seja mantida a identificagao do motorista, o numero de sua habilitagao e 
data de vencimento da mesma. A habilitagao nao pode veneer dentro do 
prazo da locagao. 

Exercicio 3.9: Estudo de caso - Sistema de preparagao de congressos da IFIP 

(Esta e a adaptagao de um conhecido estudo de caso proposto em um con- 
gresso de um grupo de trabalho da IFIP que tinha por objetivo comparar dife- 
rentes metodologias de desenvolvimento de sistemas de informagao. O es- 
tudo de caso foi concebido como estudo de caso padrao em que cada meto- 
dologia a comparar deveria ser aplicada.) 

Deseja-se construir um sistema em computador para apoiar a organiza- 
cao de congressos de trabalho da IFIP (Federacao Internacional de Processa- 
mento de Informagoes). A IFIP e uma sociedade que congrega as sociedades 
nacionais de informatica de diversos paises. 

Dentro da IFIP, atuam grupos de trabalho (GT). Cada GT trata de um 
determinado assunto. Cada GT recebe um codigo e e denominado segundo o 
assunto de que trata. Um dos objetivos de um GT e o de promover de forma 
regular congressos de trabalho. 

Um congresso de trabalho e um encontro com numero limitado de parti- 
cipantes (50-100) dos quais espera-se participagao ativa. No congresso, sao 
apresentados e discutidos trabalhos originais dos participantes. Para possibi- 
litar que os participantes obtenham financiamento para sua ida ao congresso, 
e importante assegurar que a selegao dos trabalhos apresentados seja feita de 
maneira imparcial, por especialistas reconhecidos na area do congresso. O 
congresso e identificado por um codigo e possui um nome, um local e uma 
data de realizagao. 



A IFIP recomenda que a preparacao do congresso seja feita por dois co- 
mites, o comite organizador e o comite de programa, montados especialmente 
para cada congresso. 

O comite de programa (CP) executa as funcao listadas abaixo: 

□ O CP esta encarregado da recepcao de artigos submetidos, controlando se 
eles estao dentro do prazo. Um artigo e um trabalho que um ou mais auto- 
res pretendem apresentar no congresso e que sera publicado em seus 
anais. Os anais sao normalmente publicados por editoras comerciais. Por 
isso, os artigos devem ser originais, isto e, cada artigo somente pode ser 
submetido a um congresso. Os artigos sao numerados seqiiencialmente 
dentro de um congresso, a medida que vao sendo recebidos. E necessario 
saber o titulo do artigo, bem como seus autores. 

O Antes do inicio da avaliagao dos artigos, o CP deve montar, um corpo de 
avaliadores externos, que ira ler cada artigo e emitir uma opiniao sobre o 
artigo. Normalmente, mas nao necessariamente avaliadores externos sao 
pessoas que ja participaram de congressos anteriores sobre o mesmo tema. 
Somente sera cadastrado como avaliador de um congresso aquele que, 
apos convidado para tal, o aceitar explicitamente. 

O A medida que os artigos forem sendo recebidos, eles devem ser distribul- 
dos aos avaliadores previamente cadastrados. Cada artigo deve ser distri- 
buido a pelo menos tres avaliadores. Um avaliador nunca deve estar com 
mais que um artigo em um instante no tempo. 

□ O CP esta encarregado de fazer o julgamento dos artigos. No julgamento, 
o CP decide quais artigos serao aceitos e quais serao rejeitados, com base 
nos pareceres dos avaliadores. O julgamento acontece um certo tempo de- 
pois do fim do prazo de recepgao de artigos. 

□ Apos o julgamento, o CP deve montar o programa do congresso, isto e, 
agrupar os artigos aceitos em sessSes e escolher um moderador para cada 
sessao. Uma sessao e um grupo de artigos que tratam de um assunto co- 
mum e que sao apresentados em um determinado horario. Por tratar-se de 
um congresso de trabalho, nao ha sessoes em paralelo, isto e, em um con- 
gresso, em um momento no tempo, nao pode ocorrer mais que uma ses- 
sao. Assim, a sessao e identificada pelo congresso e pelo horario em que 
ocorre. 

□ Alem das tarefas acima, o CP esta encarregado de toda comunicacao com 
os autores e com os avaliadores. 

O comite organizador (CO) esta encarregado de toda parte financeira e or- 
ganizagao local do congresso. Para fins do estudo de caso, vamos considerar 
apenas as seguintes atividades: 

O Com boa antecedencia, o CO deve emitir as chamadas de trabalho do con- 
gresso. A chamada de trabalhos e um texto que divulga o congresso e que 
convida as pessoas a submeter artigos ao congresso. Esta chamada e am- 
plamente divulgada em listas eletronicas, periodicos, etc. Alem disso ela 
deve ser enviada pessoalmente, por correio eletronico, as seguintes pes- 
soas: 

> membros dos GT que promovem o congresso 



> pessoas que de alguma forma ja participaram de congressos promovi- 
dos pelos GT que promovem o congresso 

> pessoas sugeridas para tal pelos membros dos GT que promovem o 
congresso 

Neste envio, devem ser evitadas redundances. 

□ Apos montado o programa pelo CP, o CO deve emitir os convites para 
participacao no congresso. Por tratar-se de congressos de trabalho, apenas 
pessoas convidadas podem inscrever-se. Sao convidados: 

> os autores de trabalhos submetidos ao congresso, 

> os avaliadores externos do congresso, 

> os membros do CO e do CP do congresso, e 

> os membros dos GT que promovem o congresso. 

O Finalmente, cabe ao CO executar as inscricoes dos convidados que aceita- 
rem o convite, controlando o prazo de inscrigao e verificando se a pessoa e 
efetivamente convidada. 

Observar que uma mesma pessoa pode atuar em muitas fun^Ses, mesmo 
em um mesmo congresso. A unica restricao importante e que uma pessoa nao 
pode avaliar o seu proprio artigo. 

Como na preparagao do congresso ha consideravel comunicagao entre as 
diversas pessoas envolvidas, e necessario manter sempre atualizados os da- 
dos de acesso a pessoa, como seu enderego, seu telefone, seu numero de fax e 
principalmente seu endereco de correio eletronico. 

O objetivo do exercfcio e construir um modelo ER de um banco de dados 
que sera compartilhado via Internet entre os diversos comites dos congressos 
em organizagao pela IFIP. Neste BD, estarao nao so as informagSes sobre os 
congressos em organizagao, mas tambem sobre os do passado. 

Exercfcio 3.10: Estudo de caso - Sistema de almoxarifado 
O enunciado deste trabalho foi adaptado de um livro de Peter Coad sobre 
projeto orientado a objetos. 

O almoxarifado pertence a um grupo de empresas do ramo industrial e 
serve para estocar pegas destinadas as varias empresas do grupo. Cada em- 
presa do grupo e considerada um cliente do almoxarifado. 

O almoxarifado esta organizado em corredores. Cada corredor possui 
varios receptaculos para pecas (um receptaculo e uma bacia retangular de 
material plastico). Os receptaculos sao todos do mesmo tamanho. Os corredo- 
res sao numerados e os receptaculos sao numerados por corredor. Por exem- 
plo, o receptaculo 2-10 e o decimo receptaculo do segundo corredor. 

Em uma das extremidades do almoxarifado encontra-se o setor de re- 
cepgao de pegas. La chegam as pegas entregues pelos fornecedores. Quando 
ocorre a chegada de pegas, a primeira atividade e registrar na ordem de com- 
pra a chegada das pegas. Uma copia de toda ordem de compra e sempre en- 
viada ao setor de recepcao. Assim, neste setor sempre sabe-se quais as pecas 
que estao por ser entregues. As ordens de compra sao geradas no setor de 
compras e apenas repassadas ao almoxarifado. 



Uma entrega corresponde sempre a uma ordem de compra. Entretanto, 
sao admitidas entregas parciais, isto e, entregas que nao completam a ordem 
de compra. Em uma entrega podem ser entregues diferentes quantidades de 
diferentes pegas. 

As pegas recebidas sao colocadas sobre um estrado. Este estrado e entao 
levado para o almoxarifado por uma empilhadeira e as pegas sao distribuidas 
nos receptaculos. Um estrado pode conter diferentes pegas. Para cada pega, 
procura-se um receptaculo que ja contenha unidades da pega em questao e 
que ainda tenha espaco para a carga chegada. Caso nao haja um receptaculo 
nestas condi^Ses, procura-se um receptaculo vazio. 

A saida do almoxarifado se da contra pedidos de clientes. Um pedido 
pode solicitar varios tipos de pegas. Todas pegas que atendem um pedido sao 
juntadas, embaladas e colocadas em uma rampa de carga (numerada) onde 
encosta o caminhao do cliente. Nao ha pedidos pendentes, isto e, os clientes 
sempre pedem quantidades de pegas que ha em estoque. 

O objetivo do sistema e o de aumentar o lucro do almoxarifado, aju- 
dando sua equipe a guardar e recuperar itens mais rapidamente e a conhecer 
as quantidades estocadas. 

O almoxarifado e de grande porte e constantemente ha varias empilha- 
deiras circulando por ele tanto para estocar entregas quando para buscar pe- 
gas referentes a um pedido. 

Outros detalhes do sistema sao fornecidos a seguir. 

O almoxarifado somente atende empresas. E necessario manter um ca- 
dastro de clientes com CGC, nome, endereco e telefone de contato. Para cada 
pega e necessario conhecer seu UPC ("Universal Product Code"), descripao e 
numero interno a organizacao. 

Para cada entrega, o setor de recepcao monta uma lista de distribuicao, 
que instrui o operador sobre que pegas, em quantidade ele deve estocar em 
que receptaculos. 

Para cada pedido, o setor de saida monta uma lista de busca, que instrui 
o operador sobre que pegas, em quantidade ele deve buscar em que recepta- 
culos. 

Em termos de processos, e necessario que o sistema processe o seguinte: 

□ De as ordens de distribuicao de pegas chegadas para cada chegada. 

□ De as ordens para busca para cada pedido. 

□ Mantenha a quantidade estocada de cada item e de cada receptaculo. 

□ Informe que pegas em que quantidade devem ser estocadas ou buscadas 
em que receptaculos. 

Em termos especificos de transagoes devem ser consideradas: 

□ Transagoes de chegada 

> Registro da chegada de produtos 

> Instrucoes para estocagem (em que estrado, em que receptaculos) 

> Confirmagao da estocagem em um receptaculo 

□ TransagSes de saida de produtos 

> Registro de um pedido 



> Geragao da lista de busca 

> Confirmagao da busca 

□ Consolidagao de receptaculos (juntar as pegas de mesmo tipo de dois re- 
ceptaculos diferentes) 

Em sua primeira versao o sistema ainda nao fara controle de empilha- 
deiras ou estrados dispomveis e em uso. 
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Este capitulo apresenta uma introducao sucinta ao modelo de dados que e 
usado nos sistemas de gerencia de banco de dados do tipo relacional. Nao e 
uma introducao completa a abordagem relacional. E apresentado apenas um 
conjunto minimo de conceitos, com o objetivo de permitir que o leitor com- 
preenda o projeto de bancos de dados relacionais, que e discutido nos proxi- 
mos capitulos. E specif icamente, o capitulo detalha como um banco de dados 
relacional e organizado (que estruturas de dados sao usadas, como elas estao 
relacionadas), mas nao discute como um banco de dados relacional pode ser 
modificado ou acessado, ou seja nao apresenta as linguagens de manipulacao 
de dados, como por exemplo, SQL. Para maiores detalhes sobre sistemas de 
BD relacionais, o leitor deve procurar livros especificos (ver a bibliografia 
deste capitulo). 

Alem dos SGBD relacionais, existem outros tipos de sistemas no mer- 
cado. Entretanto, hoje, ha um claro predominio dos SGBD relacionais, princi- 
palmente fora das plataformas de grande porte. Mesmo nestes ambientes, os 
SGBD relacionais estao gradativamente substituindo os SGBD de outras 
abordagens (hierarquica, rede, sistemas proprietaries). Alem disso, muitos 
conceitos usados no projeto de BD, como o conceito de normalizacao, foram 
criados em combinacao com a abordagem relacional. Por esses motivos, va- 
mos considerar unicamente a abordagem relacional neste livro. 



4.1 COMPOSIQAO DE UM BANCO DE DADOS RELACIONAL 

Um banco de dados relacional e composto de tabelas ou relagdes. A terminolo- 
gia tabela e mais comum nos produtos comerciais e na pratica. Ja a terminolo- 
gia relagdo foi utilizada na literatura original sobre a abordagem relacional (dai 
a denomina^ao "relacional") e e mais comum na area academica e nos livros- 
texto. Neste livro, preferimos adotar a terminologia usada na pratica. Entre- 
tanto, sempre que apresentarmos um novo conceito, citaremos, entre parente- 
ses, tambem a terminologia academica. 

4.1.1 Tabelas 

Uma tabela e um conjunto nao ordenado de linhas (tuplas, na terminologia 
academica). Cada linha e composta por uma serie de campos (valor de atri- 
buto, na terminologia academica). 

Cada campo e identificado por nome de campo (nome de atributo, na ter- 
minologia academica). O conjunto de campos das linhas de uma tabela que 
possuem o mesmo nome formam uma coluna. 


no me do campo 


CodiqoEmp 

Nome 

CodiqoDepto 

CateqFuncional. 

> 

E5 

Souza 

D1 

C5 

E3 

Santos 

D2 

C5 


E2 

El 

Silva 

Soares 

D1 

D1 

<nz> 



valor de campo 
(valor de atributo) 


Figura4.1: Tabela 

Comparando uma tabela de um banco de dados relacional com um ar- 
quivo convencional do sistema de arquivos de um computador, identificam- 
se as seguintes diferencas: 

□ As linhas de uma tabela nao estao ordenadas. A ordem de recuperagao 
pelo SGBD e arbitraria, a menos que a instrugao de consulta tenha espe- 
cificado explicitamente uma ordena^ao. Nao e possivel referenciar linhas 
de uma tabela por posigao. Ja em arquivos convencionais, o programa- 
dor tern controle sobre a ordem de armazenamento e pode referenciar 
registros por sua posigao relativa dentro do arquivo. 

□ Os valores de campo de uma tabela sao atomicos e mono-valor ados. Em ar- 
quivos convencionais, campos podem ser compostos por outros campos 
("itens de grupo") e campos podem ser multi-valorados ("arrays" de 
Pascal, ou grupos repetidos de COBOL). 

O As linguagens de consulta a bases de dados relacionais permitem o acesso 
por quaisquer criterios envolvendo os campos de uma ou mais linhas. Em 
arquivos convencionais, para buscar registros com base em valores de 
seus campos de forma rapida e usualmente necessario que exista algum 


tipo de caminho de acesso. Um caminho de acesso e uma estrutura auxi- 
liar, como um indice ou uma cadeia de ponteiros, que acelera a recupera- 
Cao de registros por determinados criterios, evitando a leitura exaustiva 
de todos registros de um arquivo. Caminhos de acesso tambem existem 
em bancos de dados relacionais, mas nao sao visiveis pelos programado- 
res, isto e, os programadores escrevem consultas a base de dados sem 
considerar a existencia ou nao de caminhos de acesso. 

4.1.2 Chaves 

O conceito basico para estabelecer relates entre linhas de tabelas de um 
banco de dados relacional e o da chave. Em um banco de dados relacional, ha 
ao menos tres tipos de chaves a considerar: a chave primaria, a chave alterna- 
tiva, e a chave estrangeira. 

4 . 1 . 2.1 Chave primaria 

Uma chave primaria e uma coluna ou uma combinacao de colunas cujos valo- 
res distinguem uma linha das demais dentro de uma tabela. Na tabela Emp da 
Figura 4.1, a chave primaria e a coluna CodigoEmp. A Figura 4.2 apresenta 
um exemplo de uma tabela (Dependente) que possui uma chave primaria 
composta (colunas CodigoEmp e NoDepen). Neste caso, apenas um dos valores 
dos campos que compoem a chave nao e suficiente para distinguir uma linha 
das demais, ja que tanto um codigo de empregado (CodigoEmp) pode apare- 
cer em diferentes linhas, quanto um numero de dependente (NoDepen) pode 
aparecer em diferentes linhas. E necessario considerar ambos valores 
(CodigoEmp e NoDepen) para identificar uma linha na tabela, ou seja para 
identificar um dependente. 


Dependente 


CodigoEmp 

NoDepen 

Nome 

Tipo 

DataNasc 

El 

01 

Joao 

Filho 

12/12/91 

El 

02 

Maria 

Esposa 

01/01/50 

E2 

01 

Ana 

Esposa 

05/11/55 

E5 

01 

Paula 

Esposa 

04/07/60 

E5 

02 

Jose 

Filho 

03/02/85 


Figura 4.2: Tabela com chave primaria composta 

Pela definicao acima, na tabela da Figura 4.2, qualquer combinacao de 
colunas que contenha as colunas CodigoEmp e NoDepen e uma chave prima- 
ria. Por isso, nas definicoes formais de chave primaria, exige-se que essa seja 
minima. Uma chave e minima quando todas suas colunas forem efetivamente 
necessarias para garantir o requisito de unicidade de valores da chave. Exem- 
plificando, alguem poderia considerar a combinacao de colunas CodigoEmp, 
NoDepen e Tipo como sendo uma chave primaria. Entretanto, se eliminarmos, 
desta combinacao a coluna Tipo continuamos frente a uma chave primaria. 
Portanto, a combinacao de colunas CodigoEmp, NoDepen e Tipo nao obedece 
o principio da minimalidade e nao deve ser considerada uma chave. 

Cabe salientar que, na abordagem relacional, o termo "chave" e empre- 
gado com uma conotacao diferente daquela usada na area de organizacao de 


arquivos e em alguns sistemas operacionais. Em arquivos convencionais, en- 
tende-se por chave qualquer coluna sobre a qual sera defirtido um rndice ou 
algum outro tipo de estrutura de acesso. Na abordagem relational, ao definir 
uma chave primaria, nao esta se definindo nenhum caminho de acesso. Esta 
se definindo apenas uma restrigdo de integridade, isto e uma regra que deve ser 
obedecida em todos estados validos da BD. No caso da chave primaria, a re- 
gra e a de unicidade de valores nas colunas que compoem a chave. 

4.1. 2.2 Chave estrangeira 

Uma chave estrangeira e uma coluna ou uma combinagao de colunas, cujos 
valores aparecem necessariamente na chave primaria de uma tabela. A chave 
estrangeira e o mecanismo que permite a implementagao de relacionamentos 
em um banco de dados relational. No banco de dados da Figura 4.3, a coluna 
CodigoDeptO da tabela Emp e uma chave estrangeira em relagao a chave pri- 
maria da tabela Dept. Isso significa que, na tabela Emp, nao podem aparecer 
linhas que contenham um valor do campo CodigoDeptO que nao exista na 
coluna de mesmo nome da tabela Emp. A interpretagao desta restrigao e que 
todo empregado deve estar associado a um departamento. 


Dept 


CodigoDeptO 

NomeDepto 

D1 

Compras 

D2 

Engenharia 

D3 

Vendas 


Emp 


CodigoEmp 

Nome 

CodigoDeptO 

CategFuncional 

CIC 

El 

Souza 

D1 

- 

132.121.331-20 

E2 

Santos 

D2 

C5 

891.221.111-11 

E3 

Silva 

D2 

C5 

341.511.775-45 

E5 

Soares 

D1 

C2 

631.692.754-88 


Figura 4.3: Chave estrangeira 

A existencia de uma chave estrangeira impoe restrigoes que devem ser 
garantidas em diversas situagSes de alteragao do banco de dados: 

□ Quando da inclusdo de uma linha na tabela que contem a chave estrangeira 
Neste caso, deve ser garantido que o valor da chave estrangeira aparega na 
coluna da chave primaria referenciada. No caso do exemplo da Figura 4.3, 
isso significa que um novo empregado deve atuar em um departamento ja 
existente no banco de dados. 

□ Quando da alteragao do valor da chave estrangeira 

Deve ser garantido que o novo valor de uma chave estrangeira aparega na 
coluna da chave primaria referenciada. 

□ Quando da exclusdo de uma linha da tabela que contem a chave primaria referen- 
ciada pela chave estrangeira 


Deve ser garantido que na coluna chave estrangeira nao aparega o valor da 
chave primaria que esta sendo excluida. No caso do exemplo da Figura 
4.3, isso significa que um departamento nao pode ser excluido, caso nele 
ainda existirem empregados. 

A palavra "estrangeira" usada para denominar este tipo de chave pode 
ser enganosa. Ela pode levar a crer que a chave estrangeira sempre referencia 
uma chave primaria de outra tabela. Entretanto, esta restricao nao existe. Uma 
chave primaria pode referenciar a chave primaria da propria tabela, como 
mostra a Figura 4.4. Nesta tabela, a coluna CodigoEmpGerente e o codigo de 
um outro empregado, o gerente do empregado correspondente a linha em 
questao. Como todo gerente e ele mesmo tambem um empregado, existe a 
restricao de que todo valor da coluna CodigoEmpGerente deve aparecer na 
coluna CodigoEmp. Assim, a coluna CodigoEmpGerente e chave estrangeira 
em relagao a chave primaria da propria tabela Emp. 
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CodiqoEmp 

Nome 

CodigoDepto 

CodigoEmpGerente 

E5 

Souza 

D1 

— 

E3 

Santos 

D2 

E5 

E2 
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E5 

El 

Soares 

D1 
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chave estrangeira: 
referencia a chave primaria 
da propria tabela 


Figura 4.4: Chave estrangeira dentro da propria tabela 

4.1. 2.3 Chave alternativa 

Em alguns casos, mais de uma coluna ou combinagSes de colunas podem ser- 
vir para distinguir uma linha das demais. Uma das colunas (ou combinagao 
de colunas) e escolhida como chave primaria. As demais colunas ou combina- 
qoes sao denominadas chaves alternativas. A Figura 4.5 mostra um exemplo de 
uma tabela com dados de empregados (Emp) na qual tanto a coluna 
CodigoEmp quanto a coluna CIC podem ser usadas para distinguir uma linha 
das demais. Nesta tabela, como a coluna CodigoEmp foi escolhida como chave 
primaria, diz-se que a coluna CIC e uma chave alternativa. 


Emp 


CodigoEmp 

Nome 

CodigoDepto 

CateqFuncional 

CIC 

E5 

Souza 

D1 

C5 

132.121.331-20 

E3 

Santos 

D2 

C5 
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E2 

Silva 

D1 

C2 
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El 

Soares 

D1 

— 

631.692.754-88 


Figura 4.5: Chave alternativa (coluna CIC) 

Quando, em uma tabela, mais de uma coluna ou combi nacjoes de colu- 
nas podem servir para distinguir uma linha das demais, surge a questao de 
que criterio deve-se usar para determinar qual das possiveis colunas (ou com- 


binagao de colunas) sera usada como chave primaria. No exemplo da Figura 
4.5, a questao e que criterio foi usado para preferir a coluna CodigoEmp como 
chave primaria e considerar a coluna CIC como chave altemativa. Porque CIC 
nao foi usado como chave primaria e CodigoEmp como chave altemativa? No 
fundo, se considerarmos apenas a tabela em que a coluna aparece, nao ha 
diferenca entre uma coluna ser chave primaria ou altemativa. Em ambos 
casos, apenas esta sendo especificada a unicidade de valores de chave. 
Entretanto, ao considerarmos chaves estrangeiras, a diferenciagao entre chave 
primaria e chave altemativa passa a ser relevante. Quando especificamos que 
uma chave e primaria, estamos especificando, alem da unicidade de valores, 
tambem o fato de esta coluna ser usada nas chaves estrangeiras que referen- 
dum a tabela em questao. Assim, no caso da tabela da Figura 4.5, estamos es- 
pecificando que tanto os valores de CodigoEmp quanto os valores de CIC sao 
unicos e adicionalmente que a coluna CodigoEmp sera usada nas chaves es- 
trangeiras que referenciam a tabela Emp. 

4.1 .3 Domfnios e valores vazios 

Quando uma tabela do banco de dados e definida, para cada coluna da tabela, 
deve ser especificado um conjunto de valores (alfanumerico, numerico,...) 
que os campos da respectiva coluna podem assumir. Este conjunto de valores 
e chamado de dommio da coluna ou dommio do campo. 

Alem disso, deve ser especificado se os campos da coluna podem estar 
vazios ("null" em ingles) ou nao. Estar vazio indica que o campo nao recebeu 
nenhum valor de seu dominio 6 . Na Figura 4.5, o campo CategFuncional da 
linha correspondente ao empregado de codigo El esta vazio. Isso indica que o 
empregado El nao possui categoria funcional ou que esta ainda nao foi in- 
formada. Na Figura 4.4, aparece outro exemplo de um campo vazio. No caso, 
o campo CodigoEmpGerente vazio indica que o empregado nao possui supe- 
rior hierarquico. As colunas nas quais nao sao admitidos valores vazios sao 
chamadas de colunas obrigatorias. As colunas nas quais podem aparecer cam- 
pos vazios sao chamadas de colunas opcionais. 

Normalmente, os SGBD relacional exigem que todas colunas que 
compoem a chave primaria sejam obrigatorias. A mesma exigencia nao e feita 
para as demais chaves (ver exemplo de chave estrangeira vazia na Figura 4.4). 

4.1.4 Restri^oes de integridade 

Um dos objetivos primordiais de um SGBD e a integridade de dados. Dizer que 
os dados de um banco de dados estao integros significa dizer que eles refle- 
tem corretamente a realidade representada pelo banco de dados e que sao 
consistentes entre si. Para tentar garantir a integridade de um banco de dados 
os SGBD oferecem o mecanismo de restrigoes de integridade. Uma restrigao de 
integridade e uma regra de consistencia de dados que e garantida pelo pro- 


6 Alguns tradutores e ate mesmo autores de textos sobre banco de dados em portugues 
tem usado a palavra "nulo" ao inves de "vazio", lembrando a palavra "null" em ingles. Esta 
tradu^ao nao me parece adequada, pois pode levar a confusoes entre o vazio (diferente de 
todos valores dos dominios dos campos) e o valor zero (nulo), que pode aparecer no dommio 
dos campos numericos 


prio SGBD. No caso da abordagem relational, costuma-se classificar as restri- 
coes de integridade nas seguintes categorias: 

□ Integridade de dominio 

Restricoes deste tipo especificam que o valor de um campo deve obedecer 
a definicao de valores admitidos para a coluna (o dominio da coluna). Nos 
SGBD relacionais comerciais, e posslvel usar apenas dommios pre-defini- 
dos (numero inteiro, numero real, alfanumerico de tamanho definido, 
data, ...). O usuario do SGBD nao pode definir dommios proprios de sua 
aplicagao (por exemplo, o dominio dos dias da semana ou das unidades 
da federagao). 

□ Integridade de vazio 

Atraves deste tipo de restricao de integridade e especificado se os campos 
de uma coluna podem ou nao ser vazios (se a coluna e obrigatoria ou op- 
cional). Como ja foi mencionado, campos que compoem a chave primaria 
sempre devem ser diferentes de vazio. 

□ Integridade de chave 

Trata-se da restricao que define que os valores da chave primaria e alter- 
nativa devem ser unicos. 

□ Integridade refer encial 

E a restricao que define que os valores dos campos que aparecem em uma 
chave estrangeira devem aparecer na chave primaria da tabela referenci- 
ada. 

As restricoes dos tipos acima especificados devem ser garantidas automati- 
camente por um SGBD relacional, isto e, nao deve ser exigido que o progra- 
mador escreva procedimentos para garanti-las explicitamente. Ha muitas ou- 
tras restricoes de integridade que nao se encaixam em nenhuma das catego- 
rias acima e que normalmente nao sao garantidas pelo SGBD. Essas restricoes 
sao chamadas de restricoes semdnticas. Alguns exemplos de restricoes deste 
tipo poderiam ser: 

□ Um empregado do departamento denominado "Financas" nao pode ter 
a categoria funcional "Engenheiro". 

□ Um empregado nao pode ter um salario maior que seu superior imedi- 
ato. 

4.2 Especificaqao de banco de dados relacional 

A especificacao de um banco de dados relacional (chamada de esquema do 
banco de dados) deve conter no minimo a definicao do seguinte: 

□ Tabelas que formam o banco de dados 

□ Colunas que as tabelas possuem 

□ Restricoes de integridade 

Na pratica, na definicao de esquemas relacionais sao usadas diversas 
notacoes, que variam de um SGBD para o outro. Nesta secao, vamos apre- 
sentar apenas uma notacao resumida para modelos logicos relacionais. Essa 
notacao e incompleta mas compacta, que e util para exemplos como os mos- 
trados no livro, bem como para discussSes sobre a estrutura geral do banco de 
dados, quando nao se deseja entrar no maior nivel de detalhamento. 



A Figura 4.6 apresenta o esquema correspondente as tabelas da Figura 
4.3 usando a notagao resumida. 

Emp ( CodiqoEmp , Nome. CodiaoDepto.CateqFuncional. CIC) 

CodigoDept referenda Dept 
Dept ( CodiqoDepto .Nome) 

Figura 4.6: Esquema do banco de dados da Figura 4.3 

Nesta notagao, sao listadas as tabelas e, para cada tabela, enumerados, entre 
parenteses, os nomes das colunas que compoem a tabela. As colunas que 
compoem a chave primaria aparecem sublinhadas. Apos a definicao da tabela 
aparecem as defini^oes das chaves estrangeiras que aparecem na tabela na 
forma: 

<nome de coluna ch. estrangeira> referenda <nome de tabela> 
quando tratar-se de uma chave estrangeira composta de uma unica co- 
luna, ou na forma: 

(<nome de coluna>1,<nome de coluna>2,...) referenda <nome de tabela> 

quando tratar-se de uma chave estrangeira composta por multiplas colunas. 

4.3 CONSULTAS A BASE DE DADOS 

Conforme mencionamos na introducao deste capltulo, nao e nossa intencao 
fazer uma introducao completa a abordagem relacional. Mesmo assim apre- 
sentamos um exemplo de uma consulta a um banco de dados relacional afim 
de mostrar algumas caracterfsticas importantes das linguagens relacionais. 

A linguagem usada neste exemplo e SQL, uma linguagem padrao de de- 
finicao e manipulacao do banco de dados. A instrucao abaixo refere-se a uma 
consulta sobre o banco de dados da Figura 4.6: 

SELECT Emp. Nome 

FROM Emp, Dept 

WFIERE Dept.Nome LIKE “Computagao” AND 

Emp.CodigoDepto = Dept.CodigoDepto AND 
Emp. CategFundonal=“Programador” 

A consulta acima busca os nomes dos empregados que estejam vincula- 
dos a um departamento em cujo nome aparece a palavra Computagao e que 
pertencem a categoria funcional Programador. Quanto a esta consulta, cabem 
as seguintes observagoes: 

□ Na instrucao SQL, o programador nao faz referenda a nenhum tipo de 
caminho de acesso. Quern decide que caminhos de acesso serao eventu- 
almente usados quando da execugao da instrucao e o SGBD. 

□ Quando em uma instrucao estao envolvidas duas tabelas, a associagao 
entre as linhas das duas tabelas e feita normalmente por uma operagao 
chamada de jungao ("join"). No caso do exemplo as linhas de Emp sao 
associadas as linhas de Dept pela igualdade do codigo do departamento. 


Exercicios 


Exercfcio 4.1: Considere o banco de dados relacional definido parcialmente 
abaixo (faltam as chaves da tabela Empregado): 

Empregado(CodigoEmpregado,Nome,NoPIS-PASEP) 
Dependente( CodigoEmpreaado,NoDependente .Nome) 
CodigoEmpregado referenda Empregado 
Na tabela Empregado, tanto CodigoEmpregado quanto NoPIS-PASEP podem 
ser chave primaria. Qual voce escolheria como chave primaria? Porque? 
Exercfcio 4.2: Tome um livro sobre organizagao de arquivos e veja o que signi- 
fica "chave secundaria". Explique porque o conceito de chave secundaria nao 
aparece na abordagem relacional. 

Exercfcio 4.3:Abaixo aparece um esquema parcial para um banco de dados 
relacional. Identifique neste esquema as chaves primarias e chaves estrangei- 
ras: 

Aluno (CodigoAluno,Nome,CodigoCurso) 

Curso(CodigoCurso,Nome) 

Disci plina(CodigoDisciplina, Nome, Creditos,CodigoDepartamento) 
Curriculo(CodigoCurso,CodigoDisciplina,Obrigat6ria-Opcional) 
Conceito(CodigoAluno,CodigoDisciplina,Ano-Semestre, Conceito) 
Departamento(CodigoDepartamento,Nome) 

Exercfcio 4.4: Para o banco de dados cujo esquema esta definido abaixo, ex- 
plique que verificagSes devem ser feitas pelo SGBD para garantir integridade 
referencial nas seguintes situagoes: 

a) Uma linha e inclufda na tabela Consulta. 

b) Uma linha e exclufda da tabela Paciente. 
Paciente( CodiqoConvenio,NumeroPaciente .Nome) 

CodigoConvenio referenda Convenio 
Convenio( CodiqoConvenio .Nome) 
Medico( CRM .Nome.Especializacao) 
Consulta( CodiqoConvenio.NumeroPaciente.CRM.Data-Hora ) 
(CodigoConvenio, NumeroPaciente) referencia Paciente 
CRM referencia Medico 
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Capitulo 

5 

Transformagoes 
entre modelos 


Nos capitulos anteriores, mostramos duas formas de modelagem de dados, a 
abordagem ER e a abordagem relational. Estas abordagens propoe modelar 
os dados em diferentes niveis de abstragao. A abordagem ER e voltada a mo- 
delagem de dados de forma independente do SGBD considerado. E adequada 
para construgao do modelo conceitiml. Ja a abordagem relational modela os da- 
dos a nfvel de SGBD relational. Um modelo neste nfvel de abstragao e cha- 
mado de modelo logico. 

No presente capitulo, vamos considerar a relagao entre estes dois nfveis 
de modelagem. 

Inicialmente, vamos apresentar o projeto logico de BD relational. O pro- 
jeto logico consta da transformagao de um modelo ER em um modelo logico, 
que implementa, a nivel de SGBD relational, os dados representados abstra- 
tamente no modelo ER. O termo "implemcntacao" significa que ocorre uma 
transformagao de um modelo mais abstrato para um modelo que contem mais 
detalhes de implementagao. Neste livro e tratado somente o projeto de BD 
relational. 

A seguir, vamos apresentar o processo inverso ao projeto, que e cha- 
mado de engenharia reversa de BD relational. Neste processo, parte-se de um 
modelo relacional e obtem-se um diagrama ER, que representa de forma abs- 
trata os dados armazenados no BD. 

A Figura 5.1 da uma visao geral dos dois processos de transformagao 
entre modelos. 



modelo EE 
(nfvel conceptual) 



Figura 5.1: Transformagoes entre modelo ER e modelo relacional 

5.1 VlSAO GERAL DO PROJETO LOGICO 

Um determinado modelo ER pode ser implementado atraves de diversos mo- 
delos relacionais, que contem as informagSes especificadas pelo diagrama ER. 
Todos podem ser considerados uma implementagao correta do modelo ER 
considerado. Entretanto, estes diferentes modelos relacionais podem resultar 
em diferentes performances do sistema construfdo sobre o banco de dados. 
Alem disso, os diferentes modelos relacionais podem implicar maior facili- 
dade, ou dificuldade de desenvolvimento e manutencao do sistema constru- 
ldo sobre o banco de dados. 


modelo EE 



Figura 5.2: Visao geral do projeto logico 

As regras de projeto logico aqui apresentadas sao baseadas na experien- 
cia acumulada por muitos autores no projeto de muitas bases de dados dife- 
rentes. Estas regras refletem um consenso de como deve ser projetado um 
banco de dados eficiente. 



Entretanto, o modelo por elas fornecido pode ser considerado como um 
modelo relacional initial. Nos casos em que este modelo relational inicial nao 
atende aos requisitos de performance da BD projetada, ha um processo de re- 
finamento e melhoria do modelo, ate ser atingido o modelo relacional satis- 
fatorio. 

A Figura 5.2 resume os passos do projeto logico. 

5.2 Transformaqao ER para relacional 

Nesta seqao, sao apresentadas regras para transformaqao de um modelo ER 
em um modelo relacional. 

As regras foram definidas tendo em vista dois objetivos basicos: 

□ Obter um banco de dados que permita boa performance de instrucoes de 
consulta e alteracao do banco de dados. Obter boa performance significa 
basicamente diminuir o numero de acessos a disco, ja que estes conso- 
mem o maior tempo na execuqao de uma instruqao de banco de dados. 

O Obter um banco de dados que simplifique o desenvolvimento e a manuten- 
qao de aplicaqSes. 

Estes dois objetivos sao os centrais. Alem destes, as regras de transfor- 
maqao procuram obter um banco de dados que ocupe pouco espaqo em disco. 
O objetivo de reduzir espaqo de armazenamento era ate algum tempo atras 
tao importante quanto o objetivo de melhorar performance e simplificar o 
desenvolvimento. Entretanto, nos ultimos anos, o preqo dos meios de arma- 
zenamento vem diminuindo constantemente, o que fez com que a reduqao de 
espaqo ocupado, principalmente se em detrimento dos demais objetivos, di- 
minuisse de importancia. 

Afim de alcanqar estes objetivos, as regras de traduqao foram definidas 
tendo por base, entre outros, os seguintes printipios: 

□ Evitar jingoes - ter os dados necessdrios a uma consulta em uma linica linha 
Um SGBD relacional normalmente armazena os dados de uma linha de 
uma tabela contiguamente em disco. Com isso, todos dados de uma 
linha sao trazidos para a memoria em uma operaqao de acesso a disco. 
Isso significa que, uma vez encontrada uma linha de uma tabela, seus 
campos estao todos disponiveis sem necessidade de acesso adicionais a 
disco. 

Quando for necessario buscar em disco dados de diversas linhas associ- 
adas pela igualdade de campos (por exemplo, buscar os dados de um 
empregado e os dados de seu departamento) e necessario usar a opera- 
qao de jungdo. Os SGBD procuram implementar a junqao de forma efici- 
ente, ja que ela e uma operaqao executada muito freqiientemente. 
Mesmo assim, a junqao envolve diversos acessos a disco. Assim, quando 
for possivel, e preferfvel ter os dados necessarios a uma consulta em 
uma unica linha somente, ao inves de te-los distribuidos em diversas li- 
nhas, exigindo a sua junqao. 

O Diminuir o numero de chaves primdrias 

Para a implementaqao eficiente do controle da unicidade da chave pri- 
maria, o SGBD usa normalmente uma estrutura de acesso auxiliar, um 



indice, para cada chave primaria. Indices, pela forma que sao imple- 
mentados, tendem a ocupar espago consideravel em disco. Alem disso, a 
insergao ou remogao de entradas em um indice podem exigir diversos 
acesso a disco. Assim sendo, quando for necessario escolher entre duas 
alternativas de implementagao, uma na qual dados aparecem em uma 
unica tabela e outra na qual os mesmos dados aparecem em duas ou 
mais tabelas com a mesma chave primaria e mesmo numero de linhas, a 
implementagao por uma unica tabela deve ser preferida. 

Para exemplificar, vamos considerar que se deseja armazenar dados so- 
bre clientes em um banco de dados relacional. Deseja-se armazenar, para 
cada cliente, seu codigo, seu nome, o nome da pessoa de contato, o ende- 
rego e o telefone. Este dados poderiam ser implementados atraves de 
uma das seguintes alternativas: 

Cliente (CodCliente, Nome, NomeContato,Enderego, Telefone) 

ou 

Cliente ( CodCliente .Nome.NomeContato) 

ClienteEnder ( CodCliente .Endereco, Telefone) 

CodCliente referencia Cliente 

Na primeira alternativa, o SGBD cria apenas um indice por codigo de 
cliente, a chave primaria da tabela. Na segunda alternativa, o SGBD cria, 
para cada tabela, um indice por codigo de cliente. Como cada cliente 
aparece nas duas tabelas, os dois indices possuem exatamente as mes- 
mas entradas, resultando em armazenamento e processamento dobra- 
dos. A primeira alternativa e a gerada pelas regras apresentadas neste 
capitulo. 

□ Evitar campos opcionais 

Campos opcionais sao campos que podem assumir o valor VAZIO (NULL 
em SQL). Os SGBD relacionais usualmente nao desperdigam espago pelo 
fato de campos de uma linha estarem vazios, pois usam tecnicas de 
compressao de dados e registros de tamanho variavel no armazena- 
mento interno de linhas. Alem disso, ha uma clausula de SQL que espe- 
cifica ao SGBD se o campo deve estar preenchido ou pode estar vazio. 
Assim, em principio, nao ha problemas em usar este tipo de campos. 
Uma situagao que pode gerar problemas e aquela na qual a obrigatorie- 
dade ou nao do preenchimento de um campo depende do valor de ou- 
tros campos. Neste caso, em alguns SGBD, o controle da obrigatoriedade 
deve ser feito pelos programas que acessam o banco de dados, o que 
deve ser evitado. 

Estas regras usam como entrada, alem do proprio modelo ER, tambem alguns 
conhecimentos sobre volumes de dados e volumes de transagSes. Esses co- 
nhecimentos permitem escolher uma alternativa de implementagao, quando 
diversas alternativas podem ser usadas para implementar um conceito da 
abordagem ER. 

A transformagao de um modelo ER em um modelo relacional da-se nos 
seguintes passos: 

1. Traducao inicial de entidades e respectivos atributos 


2. Tradugao de relacionamentos e respectivos atributos 

3. Tradugao de generalizagSes/especializagoes 

5.2.1 Implementa^ao inicial de entidades 

Esse passo e razoavelmente obvio: cada entidade e traduzida para uma tabela. 
Neste processo, cada atributo da entidade define uma coluna desta tabela. Os 
atributos identificadores da entidade correspondem as colunas que compoem 
a chave primaria da tabela. 

Trata-se aqui de uma tradugao inicial. Pelas regras que seguem nas pro- 
ximas segSes, as tabelas definidas nesta etapa ainda poderao ser fundidas, no 
caso de algumas alternativas de implementagao de relacionamentos 1:1 e hie- 
rarquias de generalizagao/especializagao. 

A Figura 5.3 apresenta um exemplo da transformagao de uma entidade 
em uma tabela. A figura mostra o DER e o correspondente esquema relacio- 
nal. A entidade PESSOA com seus atributos codigo, nome e enderego e trans- 
formada na tabela denominada Pessoa com colunas denominadas 
CodigoPess, Nome e Enderego. Como o atributo codigo e identificador da 
entidade, a coluna correspondente a este atributo e a chave primaria da ta- 
bela. 


data de 
admissaoO 

data deQ 
nascimento 

Esquema relacional correspondente: 

Pessoa (CodigoPess, Nome, Enderego,DataNasc,DataAdm) 

Figura 5.3: Transformagao de entidade em tabela 

5.2.1 .1 Nomes de atributos e nomes de colunas 

Nao e aconselhavel simplesmente transcrever os nomes de atributos para no- 
mes de colunas. Nomes de colunas serao referenciados frequentemente em 
programas e outras formas de texto em computador. Assim, para diminuir o 
trabalho de programadores e conveniente manter os nomes de colunas curtos. 
Alem disso, em um SGBD relacional, o nome de uma coluna nao pode confer 
brancos. Assim, nomes de atributos compostos de diversas palavras devem 
ser abreviados. Com base nestas consideragoes, os nomes de atributos data de 
nascimento e data de admissao foram traduzidos para os nomes de colunas 
DataNasc e DataAdm respectivamente. 

Nas linguagens de banco de dados, o nome da tabela e muitas vezes 
usado como qualificador do nome da coluna. Exemplificando, para referen- 
ciar a coluna Nome da tabela Pessoa muitas vezes e usado um termo na 
forma Pessoa. Nome. Por isso, nao e recomendado incluir no nome de uma 
coluna o nome da tabela em que ela aparece. Assim, e preferivel usar o nome 
de coluna Nome a usar os nomes de coluna NomePess ou NomePessoa. A 
excegao a esta regra e a coluna chave primaria da entidade. Como esta coluna 


PESSOA 


~W codigo 
“O nome 

-O p.nAp.rp.r.n 


pode aparecer em outras tabelas na forma de chave estrangeira, e recomenda- 
vel que os nomes das colunas que compoem a chave primaria sejam sufixadas 
ou prefixadas com o nome ou sigla da tabela na qual aparecem como chave 
primaria. Por este motivo, a coluna chave primaria da tabela do exemplo re- 
cebeu a denominagao de CodigoPess. 

Outra recomend a^ao quanto a nomeagao de colunas e relativa ao uso de 
abreviaturas. Muitas vezes usa-se determinadas abreviaturas para tipos de 
campos que se repetem, como Cod para um codigo e No ou Num para um 
numero. A recomendagao e que se use sempre a mesma abreviatura em toda o 
banco de dados. 

5.2.1. 2 Relacionamento identificador 

Ha uma situagao na qual a tradu^ao de uma entidade para uma tabela nao e 
trivial. Trata-se da situagao na qual uma entidade possui um relacionamento 
identificador. Um exemplo de entidade deste tipo e a entidade DEPENDENTE 
mostrada no diagrama da Figura 5.4. Um dependente e identificado pelo co- 
digo do empregado ao qual ele esta vinculado e por um numero de seqiiencia 
que distingue os diversos dependentes de um mesmo empregado. A regra de 
tradu^ao de identificadores externos e que, para cada identificador externo 
seja criada uma coluna (ou varias no caso de o identificador externo ser com- 
posto de varios atributos) na tabela em questao, coluna esta que fara parte da 
chave primaria da tabela. A Figura 5.4 mostra o esquema relacional para esta 
tradu^ao da entidade DEPENDENTE. 


numero 



Esquema relacional correspondente: 

Dependente ( CodiqoEmp.NoSeq .Nome) 

Figura 5.4: Tradugao de entidade com identificador externo 

Cabe observar que, na composigao da chave primaria de uma tabela que 
possui identificador externo, pode ser necessario colecionar atributos de di- 
versas entidades, conforme mostrado na Figura 5.5. 



numero de no me 

oequiSncia 


Esquema relacional correspondente: 

Grupo ( CodGrup .Nome) 

Empresa ( CodGrup.NoEmpresa .Nome) 

Empregado ( CodGrup.NoEmpresa.NoEmpreg .Nome) 

Dependente ( CodGrup.NoEmpresa.NoEmpreg.NoSeq .Nome) 

Figura 5.5: Chave primaria composta por diversos identificadores externos 

No caso do exemplo, para compor a chave primaria da tabela 
Dependente, e necessario, usar alem do numero de seqiiencia deste depen- 
dente, tambem o identificador do empregado. Entretanto, um empregado e 
identificado por seu numero e pelo identificador da empresa a qual ele esta 
vinculado. Por sua vez, a empresa e identificada por um numero e pelo identi- 
ficador do grupo ao qual ela pertence. Em outros termos, um dependente e 
identificado pela combinacao das seguintes informagoes: 

□ codigo do grupo da empresa a qual seu empregado esta vinculado 

□ numero da empresa a qual seu empregado esta vinculado 

□ numero de seu empregado 

□ seu numero de seqiiencia. 

Essa linha de raciocinio nos leva a chave primaria da tabela Dependente, 
que e mostrada na Figura 5.5. 

5.2.2 Implementa^ao de relacionamentos 

O fator determinante para a tradugao a adotar no caso de relacionamentos e a 
cardinalidade minima e maxima das entidades que participam do relaciona- 
mento. Antes de detalhar a alternativa proposta para cada tipo de relaciona- 


mento, apresentamos tres formas basicas de tradugao de relacionamentos 
para o modelo relacional. 

5.2.2.1 Tabela propria 

Nesta traducao, o relacionamento e implementado atraves de uma tabela pro- 
pria. Esta tabela content as seguintes colunas: 

□ colunas correspondentes aos identificadores das entidades relacionadas 

□ colunas correspondentes aos atributos do relacionamento. 

A chave primaria desta tabela e o conjunto das colunas correspondentes 
aos identificadores das entidades relacionadas. Cada conjunto de colunas que 
corresponde ao identificador de uma entidade e chave estrangeira em relagao 
a tabela que implementa a entidade referenciada. 

Um exemplo deste tipo de traducao e apresentado na Figura 5.6. A parte 
do esquema do banco de dados que se refere a regra em questao esta apre- 
sentada em negrito. Essa convengao sera usada no restante da apresentagao 
das regras de traducao de relacionamentos. 



Cod\qo Nome Fungao C6d\ap Tfculo 


Esquema relacional correspondente: 

Engenheiro ( CodEng , Nome) 

Projeto ( CodProj , Titulo) 

Atuagao ( CodEng, CopProi .Funcao) 

CodEng referenda Engenheiro 
CodProj refereneia Projeto 

Figura 5.6: Tradugao de um relacionamento para uma tabela 

A tabela Atuagao implementa o relacionamento ATUAQAO. A chave 
primaria da tabela e formada pelas colunas CodEng e CodProj, que corres- 
pondent aos identificadores das entidades relacionadas (ENGENHEIRO e 
PROJETO). Cada uma destas colunas e chaves estrangeira das tabela que im- 
plementa a entidade relacionada. A coluna Fungao corresponde ao atributo 
do relacionamento. 

5.2.2.2 Colunas adicionais dentro de tabela de entidade 

A outra alternativa de implementagao de um relacionamento e a insergao de 
colunas em uma tabela correspondente a uma das entidades que participant 
do relacionamento. Um exemplo deste tipo de tradugao e apresentado na 
Figura 5.7. Esse tipo de tradugao somente e possivel quando uma das entida- 
des que participa do relacionamento tern cardinalidade maxima um (no caso 
do exemplo, trata-se da entidade EMPREGADO). A tradugao consta em inse- 


rir na tabela correspondente a entidade com cardinalidade maxima 1 as se- 
guintes colunas: 

□ colunas correspondentes ao identificador da entidade relacionada (no 
caso do exemplo, o identificador da entidade DEPARTEAMENTO); estas 
colunas formam uma chave estrangeira em relagao a tabela que imple- 
menta a entidade relacionada - no caso do exemplo, a coluna Cod Dept 

□ colunas correspondentes aos atributos do relacionamento - no caso do 
exemplo, a coluna DataLota. 



Codlqo Nome Data \ofcagao Codigo Nome 


Esquema relacional correspondente: 

Departamento ( CodDept .Nome) 

Empregado (CodEmp, Nome, CodDept, DataLota) 

CodDept referencia Departamento 

Figura 5.7: Tradugao de relacionamento para colunas de uma tabela cor- 
respondente a uma entidade relacionada 

5.2.2.3 Fusdo de tabelas de entidades 

A terceira forma de implementar um relacionamento e atraves da fusao das 
tabelas referentes as entidades envolvidas no relacionamento. Um exemplo 
deste tipo de tradugao e apresentado na Figura 5.8. Esta tradugao somente 
pode ser aplicada quando o relacionamento e de tipo 1:1. A tradugao consta 
de implementar todos atributos de ambas entidades, bem como os atributos 
do relacionamento em uma unica entidade. 



Esquema relacional correspondente: 

Conferencia ( CodConf .Nome.DatalnstComOrq.EnderComOrq) 

Figura 5.8: Tradugao de relacionamento atraves de fusdo de tabelas 

5.2.3 Detalhes da implementa$do de relacionamentos 

A regra especifica que deve ser usada na tradugao de um relacionamento e 
determinada pelas cardinalidades minima e maxima das entidades envolvi- 


das nos relacionamentos. A Tabela 5.1 da uma visao geral das regras usadas. 
Para cada tipo de relacionamento a tabela mostra qual a alternativa que deve 
ser usada (alternativa preferida, indicada pelo simbolo ✓). Para alguns tipos 
de relacionamentos ha ainda segunda alternativa a ser usada (indicada pelo 
simbolo ±), bem como uma alternativa que nao deve ser usada (indicada pelo 
simbolo X). Nas segSes que seguem, a regra de tradugao correspondente a 
cada um dos tipos de relacionamentos e justificada e exemplificada. 


Tipo de relacionamento 

Regra de implementagao 

Tabela 

propria 

Adigao 

coluna 

Fusao 

tabelas 

Relacionamentos 1 :1 

(0.!) (0,1) 

+ 

✓ 

X 

m (i.i) 

X 

+ 

✓ 

(b 1 ) (1,1) 

X 

+ 

✓ 

Relacionamentos 1 :n 

(0.!) (Q,n) 

+ 

✓ 

X 

(O. 1 ) (bn) 

+ 

✓ 

X 

(b!) (0,n) 

X 

✓ 

X 

(b 1 ) (bn) 

X 

✓ 

X 

Relacionamentos n:n 

(0,n (0,n) 

^ <^> 

✓ 

X 

X 

( °>n (1,n) 

✓ 

X 

X 

(bn) (1,n) 

✓ 

X 

X 


%/ + X 

Alternativa preferida - Pode ser usada Nao usar 


Tabela 5.1 : Regras para implementagao de relacionamentos 


5.2.3.1 Relacionamentos 1:1 


5. 2. 3.1 .1 Ambas entidades tern participagao opcional 

A Figura 5.9 apresenta um exemplo de relacionamento 1:1 no qual a partici- 
paqao de ambas entidades e opcional (a cardinalidade minima de ambas enti- 
dades no relacionamento e zero). 

De acordo com a Tabela 5.1, a alternativa preferida de tradugao de rela- 
cionamentos e a insercao de colunas na tabela referente a uma das entidades 
que participam do relacionamento. Como e um relacionamento 1:1, qualquer 
das entidades que participam do relacionamento pode ser a escolhida. 



Identidade Nome Data Regime Identidade Nome 


Figura 5.9: Implementagao de relacionamento 1:1 com participagao 
obrigatoria de ambas entidades 

Uma solu^ao poderia ser a apresentada abaixo: 

Muiher (jdentM, Nome, IdentH, Data, Regime) 

IdentH referenda Homem 
Homem ( IdentH , Nome) 

Neste esquema, as colunas referentes ao relacionamento estao marcadas 
em negrito. Trata-se de colunas referentes aos atributos de casamento, bem 
como a coluna IdentH, chave estrangeira que implementa o relacionamento. 
Neste caso, optou-se, arbitrariamente, por adicionar colunas a tabela Muiher. 
Da mesma forma, poderiam ter sido adicionadas colunas (identificador da 
muiher e atributos de casamento) a tabela Homem. 

A outra alternativa seria a de gerar uma tabela propria para o relacio- 
namento, conforme o esquema abaixo: 

Muiher ( IdentM .Nome) 

Homem ( IdentH , Nome) 

Casamento (IdentMJdentH, Data, Regime) 

IdentM referenda Muiher 
IdentH referencia Homem 

A tabela que implementa o relacionamento e a tabela Casamento. Nesta 
tabela, as colunas IdentH e IdentM sao ambas chaves estrangeiras, implemen- 
tando desta forma a vinculagao da linha de casamento as linhas de homem e 
muiher correspondentes. Como se trata de um relacionamento 1:1, tanto a 
coluna IdentH quanto a coluna IdentM podem ser consideradas para a chave 
primaria. No exemplo, a coluna IdentM foi escolhida arbitrariamente como 
chave primaria, sendo IdentH uma chave alternativa. 


A primeira alternativa e a preferida, pois minimiza a necessidade de 
jun^Ses, ja que os dados de uma pessoa (na op^ao escolhida a mulher) estao 
na mesma linha que os dados do casamento. 

A desvantagem da primeira alternativa e que pode levar a utilizagao da 
segunda alternativa e a de basear-se no uso de cohinas opcionais, isto e, no uso 
de colunas que admitem valores vazios (no exemplo, as colunas IdentH, Data 
e Regime da tabela Mulher). Esta alternativa transfere a responsabilidade pela 
verificagao da opcionalidade de campos do SGBD para os programas que atu- 
alizam o banco de dados. No caso da tabela Mulher do exemplo, nas linhas 
que correspondem a mulheres que nao sao casadas os campos corresponden- 
tes ao casamento devem estar todos vazios. Ja nas linhas correspondentes a 
mulheres casadas os tres campos devem estar preenchidos. Nao ha linhas em 
que, dentre os tres campos, alguns estao vazios e outros preenchidos. O con- 
trole que garante que os tres campos estao preenchidos ou que os tres campos 
estao vazios nao e feito pelo SGBD, e com isso tern que ser feito pela propria 
aplicagao. 

Cabe observar que em alguns SGBD, que implementam restrigSes de 
integridade (clausula "Assertion" ou similar) e possivel transferir ao SGBD a 
responsabilidade pelo controle das colunas opcionais. Neste caso, a segunda 
alternativa seria a preferida. 

5. 2. 3. 1.2 Uma entidade tem participagao opcional e a outra tem participa- 
gao obrigatoria 

Outra tipo de relacionamento 1:1; e aquele no qual uma das entidades tem 
participacao obrigatoria, enquanto que a outra entidade tem participagao opci- 
onal (a cardinalidade minima de uma das entidades e um, a cardinalidade mi- 
nima da entidade e zero). Um exemplo desta situagao e apresentada na Figura 
5.10. 



Cod\qo Nome Codigo Data Exp. 


Esquema relacional correspondente: 

Correntista ( CodCorrent .Nome.CodCartao, DataExp) 

Figura 5.10: Implementagao de relacionamento com participagao obriga- 
toria de uma entidade e participagao opcional da outra 

Neste caso, a tradupao preferida e atraves da fusao das tabelas corres- 
pondentes as duas entidades. 

Alternativamente, poderia ser considerada a tradugao atraves da adigao 
de colunas a tabela correspondente a entidade com cardinalidade minima 0. 
No caso do exemplo, a tradugao resultaria no esquema abaixo: 


Correntista ( CodCorrent .Nome) 

Cartao( CodCartao ,DataExp,CodCorrent) 

CodCorrent referenda Correntista 

5.2.3. 1 .3 Ambas entidades tern participagao obrigatoria 

O ultimo tipo de relacionamentos 1:1 e aquele na qual ambas entidades tern 
participagao obrigatoria no relacionamento (a cardinalidade minima de ambas 
entidades e um). Um exemplo desta situagao e apresentada na Figura 5.11. 



Esquema relacional correspondente: 

Conferencia ( CodConf .Nome.DatalnstComOrq.EnderComOrq) 

Figura 5.1 1 : Implementagao de relacionamento 1:1 com participagao obri- 
gatoria de ambas entidades 

Neste caso, a tradugao preferida e atraves da fusao das tabelas corres- 
pondentes as duas entidades. 

Nenhuma das demais alternativas atende plenamente. Em ambas alter- 
nativas, as entidades que participam do relacionamento seriam representadas 
atraves de duas tabelas distintas. Estas tabelas teriam a mesma chave primaria 
e relagao um-para-um entre suas linhas. Essa implementagao viola os princi- 
pios de evitar juncoes e diminuir o numero de chaves primarias estabelecidos 
no inicio do capitulo. 

S.2.3.2 Relacionamentos 1:n 

No caso de relacionamentos l:n, a alternativa preferida de implementagao e a 
de adigao de colunas (Segao 5. 2.2. 2). 

Um exemplo desta tradugao e apresentado na Figura 5.12. 

Cabe observar que no caso particular deste exemplo, a coluna CodigoEd 
da tabela Apartamento (que implementa o relacionamento do apartamento 
com seu edificio), alem de ser chave estrangeira, e tambem parte da chave 
primaria. Esta situa^ao e tipica de uma entidade com relacionamento identifica- 
dor, cuja tradugao foi discutida na Segao 5.2.1. 2. 

No caso de a entidade com cardinalidade maxima 1 ser opcional, isto e, 
possuir cardinalidade minima 0, poderia ser considerada uma implementagao 
alternativa. Um exemplo deste tipo de relacionamento e mostrado na Figura 
5.13. A entidade VENDA esta opcionalmente ligada a entidade FINANCEIRA. 



Codigo E nderego Numero Area 


Esquema relacional correspondente: 

Edificio ( CodigoEd , Enderego) 

Apartamento ( CodigoEd, NumeroAp .AreaAp) 

CodigoEd referencia Edificio 

Figura 5. 1 2: Tradugao de relacionamentos 1 :n atraves de adigao de colunas 



Figura 5. 1 3: Tradugao de relacionamentos 1 :n no qual a entidade com car- 
dinalidade maxima um e opcional 

Para este tipo de relacionamento, pode ser usada alternativamente im- 
plementagao atraves de tabela propria. 

A implementagao atraves de adigao de colunas a tabela de entidade Venda 
(implementagao preferida) e a seguinte: 

Financeira ( CodFin .Nome) 

Venda ( ldVend ,Data,CodFin,NoParc,TxJuros) 

CodFin referencia Financeira 

As colunas em negrito na tabela Venda implementam o relacionamento. 
A implementagao atraves de tabela propria (implementagao alternativa) e 
a seguinte: 

Financeira ( CodFin .Nome) 

Venda ( IdVend .Data) 

Fianciam ( IdVend , CodFin, NoParc.TxJuros) 

IdVend referencia Venda 
CodFin referencia Financeira 

A implementagao por tabela propria tem duas desvantagens em relagao 
a implementagao por adigao de colunas: 

□ Operagoes que envolvem acesso a dados de uma venda e do respectivo 
financiamento exigem jungoes. Na primeira alternativa, isto nao ocorre, 
ja que os dados da venda e de seu financiamento estao na mesma linha. 


□ As tabelas Venda e Fianciam possuem a mesma chave primaria, sendo o 
conjunto de valores de Fianciam um subconjunto de Venda. Tem-se o 
problema acima mencionado de armazenamento e processamento dupli- 
cados de chave primaria. 

A unica vantagem que a implementagao por tabela propria apresenta e o 
fato de nela haver campos que sao opcionais em certas linhas e obrigatorios 
em outras. Este e o caso dos campos CodFin, NoParc e TxJuros da tabela 
Venda na alternativa de adigao de colunas. Estes campos estao obrigatoria- 
mente preenchidos em caso de venda a prazo e vazios em caso contrario. 

5.2.3.3 Relacionamentos n:n 

Independentemente da cardinalidade minima, relacionamentos n:n, sao sem- 
pre implementados atraves de uma tabela propria. Um exemplo de imple- 
mentagao de relacionamentos n:n e apresentado na Figura 5.6. 

A alternativa de adicionar colunas a uma das tabelas correspondentes as 
entidades que participam do relacionamento nao e aplicavel. Cada entidade 
esta associada a um numero variavel de entidades. Para implementar o relaci- 
onamento atraves da adigao de colunas, seria necessaria uma coluna multi- 
valorada, que comportasse um conjunto de valores de chaves primarias, refe- 
rente a entidade associada. Entretanto, como vimos no capitulo anterior, as 
colunas na abordagem relacional sao sempre mono-valor adas. Assim, esta al- 
ternativa nao e viavel pelas proprias caracteristicas da abordagem relacional. 

5.2.3.4 Relacionamentos de grau maior que dois 

As regras apresentadas ate este ponto, aplicam-se somente a implementagao 
de relacionamentos binarios, isto e, que envolvem apenas duas entidades. 
Para relacionamentos de grau maior que dois, nao sao definidas regras especi- 
ficas. A implementagao de um relacionamento de grau maior que dois da-se 
na seguinte seqiiencia de passos: 

1 O relacionamento e transformado em uma entidade. Esta nova entidade 
e ligado atraves de um relacionamento binario a cada uma das entidades 
que participavam do relacionamentos original. 

2 As regras de implementagao de entidades e relacionamentos binarios 
apresentadas acima sao aplicadas as entidades e aos relacionamentos bi- 
narios assim criados. 

A Figura 5.14 mostra um relacionamento ternario junto com sua trans- 
formagao em uma entidade e tres relacionamentos binarios. 

A implementagao deste modelo seguindo as regras apresentadas acima 
resulta no seguinte esquema relacional: 

Produto ( CodProd .Nome) 

Cidade ( CodCid .Nome) 

Distribuidor ( CodDistr .Nome) 

Distribuigao ( CodProd.CodDistr.CodCid .Nome) 

CodProd referenda Produto 
CodDistr referenda Distribuidor 
CodCid referencia Cidade 



Figura 5.14: Relacionamento ternario (a) e sua transformagao em entidade 
e relacionamentos binarios (b) 

5.2.4 Implementa^ao de generalizacaoespecializacao 

Para a implementagao de hierarquias de generalizagao/especializagao na 
abordagem relacional, ha duas alternativas a considerar: (1) uso de uma tabela 
para cada entidade e (2) uso de uma unica tabela para toda hierarquia de ge- 
neralizagao/ especial iza^ao. A seguir apresentamos as duas alternativas, para, 
depois, discutir quando usar uma ou outra. 

5.2.4.1 Uma tabela por hierarquia 

Nesta alternativa, todas tabelas referentes as especializagSes de uma entidade 
generica sao fundidas em uma unica tabela. Esta tabela tera: 

□ Chave primaria correspondente ao identificador da entidade mais gene- 
rico 

□ Caso nao exista, uma coluna Tipo, que identifica que tipo de entidade 
especializada esta sendo representada por cada linha da tabela 

□ Uma coluna para cada atributo da entidade generica 

□ Colunas referentes aos relacionamentos dos quais participa a entidade 
generica e que sejam implementados atraves da alternativa de adicionar 
colunas a tabela da entidade generica 

□ Uma coluna para cada atributo de cada entidade especializada (estas 
colunas devem ser definidas como opcionais, ja que somente terao valo- 
res quando a linha for referente a entidade especializada em questao) 

□ Colunas referentes aos relacionamentos dos quais participa cada enti- 
dade especializada e que sejam implementados atraves da alternativa de 
adicionar colunas a tabela da entidade (estas colunas devem ser defini- 
das como opcionais, ja que somente terao valores quando a linha for re- 
ferente a entidade especializada em questao) 

Observe-se que, pela definigao acima, uma entidade especializada pode 
nao gerar nenhuma coluna na implementagao. Isto ocorrera caso a entidade 
especializada nao tenha atributos e caso todos relacionamentos dos quais ele 
participe sejam implementados atraves de tabelas proprias. 


Um exemplo de implementagao usando uma unica tabela para toda hie 
rarquia de especializagao da entidade EMPREGADO aparece na Figura 5.15. 

ti po de 



cod\qo nome codlqo no me codlqo nome 


Esquema relacional correspondente: 

Emp ( CodigoEmp , Tipo, Nome. CIC, CodigoDept, 

CartHabil,CREA,C6digoRamo) 

CodigoDept referenda Depto 
CodigoRamo referenda Ramo 
Depto ( CodigoDept , Nome) 

Ramo ( CodigoRamo , Nome) 

ProcessTexto ( CodigoProc .Nome) 

Domfnio ( CodiqoEmp.CodigoProc ) 

CodigoEmp referencia Emp 
CodigoProc referencia ProcessTexto 
Projeto ( CodigoProi .Nome) 

Parti cipagao ( CodigoEmp, CodiqoProi ) 

CodigoEmp referencia Emp 
CodigoProj referencia Projeto 

Figura 5.15: Hierarquia de generalizagao/especializagao e sua implementa- 
gao atraves de tabela unica 

A tabela Emp, que implementa a entidade EMPREGADO e suas especi 
alizagSes, contem as seguintes colunas: 


□ CodigoEmp, chave primaria da tabela, correspondente ao identificador 
da entidade 

□ As colunas Tipo, Nome e CIC referentes aos atributos da entidade gene- 
rica 

□ A coluna CodigoDept, que implementa o relacionamento LOTAQAO 

□ A coluna CartHabil que implementa os atributos da entidades especiali- 
zada MOTORIST A 

O A coluna CREA que implementa os atributos da entidade especializada 
ENGENHEIRO 

O A coluna CodigoRamo, que implementa o relacionamento entre 
ENGENHEIRO e RAMO DA ENGENHARIA 

Pelas regras apresentadas na sepao anterior, os relacionamentos 
PARTICIPAQAO e DOMiNIO sao implementados por tabela propria, nao ge- 
rando colunas na tabela correspondente a hierarquia de generaliza- 
pao/especializapao. Alem disso, a entidade SECRETARIA nao gera nenhuma 
coluna ja que nao possui atributos nem participa de relacionamentos que ge- 
rem colunas. 

As colunas que correspondem as entidades especializadas (CartHabil, 
CREA e CodigoRamo) devem ser definidas todas como colunas opcionais. 
Essa definipao e necessaria, pois uma linha referente a um empregado, que 
nao pertenpa a nenhuma das classes especializadas, tera todos campos acima 
listados vazios. Ja uma linha correspondente a uma entidade especializada 
tera alguns campos vazios e outros preenchidos. Exemplificando, uma linha 
referente a um engenheiro teria os campos CREA e CodigoRamo preenchidos 
e o campo CarHabil vazio. 

As demais tabelas que implementam o modelo da figura 6.14, definidas 
usando as regras apresentadas nas sepoes anteriores sao: 

□ Tabela Depto que implementa a entidade DEPARTAMENTO 

□ Tabela Ramo que implementa a entidade RAMO DA ENGENHARIA 

□ Tabela ProcessTextO que implementa a entidade PROCESSADOR DE 
TEXTO 

□ Tabela Domlnio que implementa o relacionamento DOMiNIO 

□ Tabela Projeto que implementa a entidade PROJETO 

□ Tabela Participapao que implementa o relacionamento PARTICIPAQAO 

5 2.4.2 Uma tabela por entidade especializada 

A outra alternativa de implementapao de uma hierarquia de generaliza- 
pao/especializapao e criar uma tabela para cada entidade que compSe a hie- 
rarquia, aplicando as regras correspondentes a implementapao de entidades e 
relacionamentos ja apresentadas nas sepSes anteriores. 

O unico acrescimo que deve ser feito aquelas regras e a inclusao da 
chave primaria da tabela correspondente a entidade generica., em cada tabela 
correspondente a uma entidade especializada Exemplificando, a implementa- 
pao do modelo ER da Figura 5.15 resultaria no seguinte esquema relacional 
(parte referente a hierarquia de generalizapao/especializapao em negrito): 


Emp ( CodigoEmp , Tipo, Nome, CIC, CodigoDept) 

CodigoDept referenda Depto 
Motoristaf CodiqoEmp .CartHabil) 

CodigoEmp referenda Emp 
Enqenheirof CodiqoEmp .CREA.CodiqoRamo) 

CodigoEmp referenda Emp 
CodigoRamo referenda Ramo 
Depto ( CodigoDept , Nome) 

Ramo ( CodigoRamo , Nome) 

ProcessTexto ( CodiooProc .Nome) 

Domlnio ( CodigoEmp, CodiooProc ) 

CodigoEmp referencia Emp 
Codigo Proc referencia ProcessTexto 
Projeto ( CodigoProi .Nome) 

Parti cipagao ( CodigoEmp, CodiooProi ) 

CodigoEmp referencia Emp 
CodigoProj referencia Projeto 

Para a entidade EMPREGADO e cada uma de suas especializagSes, foi criada 
uma tabela. Estas tabelas tem todas a mesma chave primaria. A tabela Emp 
contem uma linha para cada empregado, independentemente de seu tipo. 
Nela aparecem as informagoes comuns a todos os empregados. As informa- 
goes referentes a cada tipo particular de empregado estao nas tabelas 
Motorista e Engenheiro. Em cada uma destas tabelas aparecem linhas somente 
para empregados pertencentes ao tipo representado pela tabela. 

Nas tabelas referentes as entidades especializadas, a chave primaria e 
tambem chave estrangeira em relagao a tabela de empregados. Isso ocorre 
porque a toda ocorrencia de uma entidade especializada corresponde uma 
ocorrencia de entidade generica, ou seja, a toda linha de uma tabela de enti- 
dade especializada corresponde uma linha da tabela da entidade generica. 

5.2.4.3 Comparaqdo entre as duas alternativas de implementa<;ao 

A seguir sao discutidas as vantagens de cada tipo de implementagao em rela- 
gao a outra. 

□ Vantagens da implementagao com tabela linica 

• Todos os dados referentes a uma ocorrencia de entidade generica, 
bem como os dados referentes a ocorrencias de sua especializagao, 
estao em uma unica linha. Nao ha necessidade de realizar jungoes 
quando a aplicagao deseja obter dados referentes a uma ocorrencia de 
entidade generica juntamente com uma ocorrencia de entidade espe- 
cializada. 

• A chave primaria e armazenada uma unica vez, ao contrario da alter- 
nativa com multiplas tabelas, na qual a chave primaria aparece tanto 
na tabela referente a entidade generica quanto na tabela referente a 
entidade especializada. 


□ Vantagens da implementagao com uma tabela por entidade especializada 

• As colunas opcionais que aparecem sao apenas aquelas referentes a 
atributos que podem ser vazios do ponto de vista da aplicagao. Na 
solugao altemativa, todas colunas referentes a atributos e relaciona- 
mentos das entidades especializadas devem ser definidas como opci- 
onais. 

• O controle de colunas opcionais passa a ser feito pela aplicagao com 
base no valor da coluna TIPO e nao pelo SGBD como ocorre na solu- 
gao alternativa. 

O projetista devera ponderar os pros e contras de ambas solugSes e op- 
tar por aquela que, considerando os fatores acima, seja a mais adequada ao 
seu problema. 

5. 2. 4.3.1 Subdivisao da entidade generica 

Alem das duas alternativas acima, alguns textos de projeto de banco de dados 
apresentam uma terceira implementagao para a generalizagao /especializagao. 
Nesta alternativa, cria-se uma tabela para cada entidade especializada que 
nao possua outra especializagao (entidade folha da arvore). Esta tabela con- 
tem tanto os dados da entidade especializada, quanto os de suas entidades 
genericas. No caso do modelo ER da Figura 5.15 a implementagao e a apre- 
sentada abaixo (parte referente a hierarquia de generalizagao /especializagao 
em negrito): 

EmpOutros ( CodiqoEmp .Tipo.Nome, CIC, CodigoDept) 

CodigoDept referenda Depto 
Motoristaf CodiqoEmp , Nome, CIC, CodigoDept, CartHabil) 
Enqenheirof CodiqoEmp , Nome, CIC, CodigoDept, 

CREA,CodigoRamo) 

CodigoRamo referenda Ramo 

Depto ( CodigoDept , Nome) 

Ramo ( CodigoRamo , Nome) 

ProcessTexto ( CodiooProc .Nome) 

Domlnio ( CodigoEmp.CodigoProc ) 

Codigo Proc referencia ProcessTexto 
Projeto ( CodiooProL Nome) 

Parti cipagao ( CodigoEmp.CodigoProi ) 

CodigoProj referencia Projeto 

A diferenga desta alternativa em relagao a anterior e que, nesta alterna- 
tiva, as tabelas correspondentes as especializagoes contem, nao so os atributos 
da entidade especializada, mas tambem os atributos de suas generalizagoes. A 
tabela contem nao so os atributos especificos da entidade MOTORIST A, mas 
tambem os atributos referentes a sua generalizagao (atributos CodigoEmp, 
Tipo,Nome, CIC e CodigoDept). De forma analoga, a tabela Engenheiro con- 
tem nao so os atributos especificos de engenheiro, mas tambem os de pessoa. 
Finalmente, a tabela EmpOutros contem dados de todas as demais categorias 
de empregados. 


E importante observar que nesta alternativa, as colunas CodigoEmp que 
aparecem como chave nas tabelas referentes as diversas especializagSes de 
empregado nao sao chave estrangeira, ja que nao existe uma tabela onde to- 
dos empregados estao reunidos, como ocorria na alternativa anterior. Alem 
disso, quando a especializagao for total (e nao parcial como no caso de exem- 
plo), deixa de existir a tabela que coleciona as linhas referentes a entidades 
para as quais nao ha especializagao (no caso do exemplo, a tabela 
EmpOutros). 

Essa alternativa tern como vantagens sobre as anteriores o fato de elimi- 
nar os problemas de colunas opcionais e chaves primarias redundantes, tipi- 
cos das solucoes anteriormente apresentadas. Entretanto, esta alternativa 
apresenta uma desvantagem do ponto de vista funcional que sobrepuja as 
vantagens que oferece do ponto de vista do uso mais eficiente de recursos. 
Nesta alternativa, para garantir a unicidade da chave primaria, a aplicagao 
que faz inclusoes de linhas de empregados deve verificar todas as tabelas re- 
ferentes as especializagSes. Exemplificando, quando for incluido um novo 
empregado, a aplicagao devera testar a sua existencia nas tres tabelas 
(EmpOutros, Motorista e Engenheiro). Essa verificagao fica a cargo da aplica- 
gao, ja que os SGBD relacionais nao sao capazes de realiza-la automatica- 
mente. Pior ainda, nao ha como especificar ao SGBD restrigoes de integridade 
referenciais, que fagam referenda ao conjunto de empregados como um todo 
(ja que este nao aparecem no banco de dados). Exemplificando, as restrigoes 
de integridade referenciais que apareciam nas solucoes anteriores, e que espe- 
cificam que as colunas CodigoEmp que aparecem nas tabelas Domlnio e 
Parti cipapao sao chaves estrangeiras em relagao ao conjunto de todos empre- 
gados, nao podem ser especificadas. 

5.2.5 Refinamento do modelo relacional 

Em todo processo de engenharia, esta envolvido um compromisso entre o 
ideal e o realizavel dentro das restrigSes de recursos impostas pelas pratica. 
No processo de engenharia de banco de dados, particularmente na imple- 
mentagao de modelos conceituais, as vezes tambem e necessario tragar um 
compromisso entre o ideal, representado pelas regras de implementagao apre- 
sentadas, e o a alcangavel frente a limitagoes de performance. Algumas vezes, 
o esquema de BD criado atraves do uso das regras acima nao atende plena- 
mente os requisitos de performance impostos ao sistema. Neste caso, e neces- 
sario buscar um alternativa de implementagao que resulte em melhor perfor- 
mance do sistema. Cabe salientar, que estas altemativas somente deveriam ser 
tentadas em ultimo caso, pois, do ponto de vista do desenvolvimento de pro- 
gramas sobre o banco de dados, sao sempre piores que as alternativas que ha- 
viam sido apresentadas anteriormente. Nas segoes abaixo, apresentamos al- 
guns exemplos de alternativas de implementagao que podem ser adotas. 

5.2.5. 1 Relacionamentos mutuamente exclusivos 

Um caso que permite uma implementagao alternativa a especificada pelas re- 
gras acima e aquele no qual uma entidade participa de forma mutuamente ex- 
clusiva de dois ou mais relacionamentos. Participar de forma mutuamente ex- 


clusiva significa que uma ocorrencia da entidade que participa de um dos re- 
lacionamentos em questao, nao participa de nenhum dos demais relaciona- 
mentos. Um exemplo e apresentado na Figura 5.16. Pode-se supor que uma 
ocorrencia da entidade VENDA participe de exatamente um dos dois relacio- 
namentos e de somente de um deles. Observe que esta informagao nao esta 
contida no diagrama, ja que nao ha uma convengao para registra-la no DER 7 . 
Ela deveria estar registrada em alguma documentagao paralela. 


CIC nome N° data 



CGC razao 
social 


Figura 5.16: Relacionamentos mutuamente exclusivos 

A implementagao para este modelo, caso forem seguidas as regras apre- 
sentadas, e a seguinte: 

PessFis( CIC .Nome) 

Pess J u r(CGC, RazSoc) 

VendafNo, data, CIC, CGC) 

CIC referenda PessFis 
CGC referenda PessJur 

Nesta implementagao, as colunas CIC e CGC sao especificadas como op- 
cionais, ja que em cada linha um ou outro campos serao vazios. Aparecem as- 
sim os problemas tipicos de colunas opcionais. Uma implementagao alterna- 
tiva e criar uma unica coluna na qual aparece o CIC ou o CGC do comprador, 
conforme mostrado abaixo. 

PessFis( CIC .Nome) 

Pess J u r(CGC, RazSoc) 

Venda(No,data,CIC/CGC,TipoCompr) 

Alem da fusao das colunas CIC e CGC, deve ser criada uma coluna 
TipoCompr, que informa se o campo na coluna CIC/CGC e referente a um 
comprador pessoa fisica ou a uma pessoa juridica. Atraves desta alternativa 


7 Algumas notacoes de diagramas ER preveem notagoes especfficas para a mutua 
exclusao entre relacionamentos. 


evita-se o uso de colunas opcionais. Entretanto, a alternativa apresenta igual- 
mente uma desvantagem. Nesta alternativa, nao e possivel especificar ao 
SGBD que o campo CIC/CGC e chave estrangeira, ja ele nao referenda uma 
unica tabela, mas duas (PessFis e PessJur), de forma alternativa de acordo 
com o valor do campo TipoCompr. 

S.2.5.2 Simulacdo de atributos multi-valorados 

Conforme discutimos no capitulo 4, atributos multi-valorados nao sao deseja- 
veis em diagramas ER, ja que nao possuem implementagao direta na aborda- 
gem relational. A Figura 5.17 apresenta um diagrama ER com atributos multi- 
valorados e o diagrama obtido pela transformagao do atributo multi-valorado 
em uma entidade separada. 




TELEFONE 


numero de 
telef one (0,n) 


1 


numero 


Figura 5.17: Eliminando atributos multi-valorados 

A implementagao do diagrama da Figura 5.17, caso sejam seguidas as 
regras apresentadas, e a seguinte: 

Cliente ( CodCli .Nome) 

Telefone ( CodCIi, Numero ) 

CodCIi referenda Cliente 

Entretanto, esta implementagao pode trazer problemas de performance, 
conforme discutido abaixo. Consideremos as seguintes condigSes de con- 
torno: 

□ Sao raros os clientes que possuem mais que dois telefones. Quando isso 
ocorrer, e suficiente armazenarmos apenas dois numeros. 

□ Nao ha consultas ao banco de dados usando o numero de telefone como 
criterio de selegao. Os numeros de telefone sao apenas exibidos ou im- 
presses juntos as demais informagSes de cliente. 

Neste caso, uma implementagao "desnormalizada" 8 como a mostrada 
abaixo pode permitir maior performance: 

Cliente ( CodCIi , Nome. NumTell ,NumTel2) 

Nesta implementagao, optou-se por simular uma coluna multi-valorada 
atraves da criagao de diversas colunas NumTel sufixadas por um numero para 


8 No proximo capitulo veremos o conceito de normalizagao. 


distingm-las. Essa alternativa permite que os telefones de um cliente sejam 
obtidos mais rapidamente, ja que encontram-se todos dentro da mesma linha 
da tabela. Alem disso, implica em menos espago ocupado, ja que o espago ne- 
cessario a implementagao da chave primaria da tabela Telefone, na primeira 
alternativa, e consideravel. O inconveniente que esta alternativa apresenta do 
ponto de vista funcional e que uma eventual consulta usando o numero de 
telefone como criterio de busca torna-se mais complicada, ja que devem ser 
referenciados todos os nomes das colunas referentes ao atributo multi-valo- 
rado 

5.2.5.3 Informagoes redundantes 

Como vimos na Segao 3.3.3, informagSes redundantes, que podem ser obtidas 
a partir de outras existentes no banco de dados, devem ser eliminadas do mo- 
delo conceitual. Entretanto, por questoes de performance, muitas vezes, 
quando do projeto do banco de dados, informagoes redundantes sao reinseri- 
das no esquema. Isso ocorre muito freqiientemente com atributos que resul- 
tam de uma operagao que envolve diversas entidades do banco de dados. 
Caso o valor destes atributos tenha que ser obtido com freqiiencia ou sirva 
freqiientemente como criterio de busca de informagoes no banco de dados, 
pode ser mais eficiente, do ponto de vista da performance global do sistema, 
armazenar o atributo derivado redundantemente. 



Figura5.18: Atributo redundante 

A Figura 5.18 apresenta um exemplo no qual aparece um atributo re- 
dundante. Trata-se do atributo numero de reservas, que pode ser obtido pela 
contagem de todas as reservas relacionadas ao voo. Assim, do ponto de vista 
conceitual, o atributo numero de reservas deveria ser eliminado. Entretanto, 
do ponto de vista de performance, provavelmente seria importante manter 
uma coluna com este valor, visto que ele seria necessario em um grande nu- 
mero de buscas no banco de dados e sua computagao freqiiente demandaria 
tempo excessivo. 

5.3 Engenharia reversa de modelos relacionais 

De forma geral, um processo de engenharia reversa pode ser definido como e 
um processo de abstragao, que parte de um modelo de implementagao e re- 


sulta em um modelo conceitual que descreve abstratamente a implementagao 
em questao. O termo engenharia reversa vem do fato de usar-se como ponto de 
partida do processo um produto implementado (o modelo de implementagao) 
para obter sua especificagao (o modelo conceitual). 

No caso de banco de dados, fala-se de engenharia reversa, quando trans- 
forma-se modelos de banco de dados mais ricos em detalhes de implementa- 
gao em modelos de dados mais abstratos. 

Um caso especifico de engenharia reversa de banco de dados e o da 
engenharia reversa de modelos relacionais. Neste tipo de engenharia reversa, tem- 
se, como ponto de partida, um modelo logico de um banco de dados relacio- 
nal e, como resultado, um modelo conceitual, no caso deste livro, na aborda- 
gem ER. Este e o processo inverso ao de projeto logico. 

A engenharia reversa de modelos relacionais pode ser util quando nao 
se tern um modelo conceitua para um banco de dados existente. Isso pode 
acontecer quando o banco de dados foi desenvolvida de forma empirica, sem 
o uso de uma metodologia de desenvolvimento, ou quando o esquema do 
banco de dados sofreu modificagSes ao longo do tempo, sem que as mesmas 
tenham sido registradas no modelo conceitual. 

Conforme veremos no Capitulo 6, a engenharia reversa de modelos rela- 
cionais e um passo dentro de um processo mais amplo de engenharia reversa 
de arquivos e documentos convencionais. 

"engenharia reversa:de modelos relacionais:processo"0 processo de en- 
genharia reversa de um modelo relacional consta dos seguintes passos: 

1. Identificagao da constru^ao ER correspondente a cada tabela 

2. Definigao de relacionamentos l:n e 1:1 

3. Definicao de atributos 

4. Definicao de identificadores de entidades e relacionamentos 

Estes passos sao detalhados nas segSes que seguem. O processo sera 
exemplificado sobre um banco de dados para um sistema academico, cujo es- 
quema e apresentado abaixo. 

Disciplina ( CodDisc .NomeDisc) 

Curso ( CodCr .NomeCr) 

Currie ( CodCr, CodDisc , Obr/Opc) 

CodCr referencia Curso 
CodDisc referencia Disciplina 
Sala ( CodPr, CodSI , Capacidade) 

CodPr referencia Predio 
Predio ( CodPr , Endereco) 

Turma ( Anosem, CodDisc, SiqlaTur .Capacidade.CodPr.CodSI) 

CodDisc referencia Disciplina 
(CodPr, CodSI) referencia Sala 
Laboratorio ( CodPr, CodSI , Equipam) 

(CodPr, CodSI) referencia Sala 


5.3.1 Identificagao da constru^ao ER correspondente a 
cada tabela 

Na primeira etapa da engenharia reversa de um banco de dados relational, 
define-se, para cada tabela do modelo relational qual a construgao que lhe 
corresponde a nfvel de modelo ER. 

Uma tabela pode corresponder a: 

□ uma entidade 

□ um relacionamento n:n 

□ uma entidade especializada 

O fator determinante da constru^ao ER que corresponde a uma tabela e 
a composigao de sua chave primaria. Tabelas podem ser classificadas em tres 
tipos de acordo com sua chave primaria: 

□ Regra 1: Chave primaria composta por mais de uma chave estrangeira 

A tabela que possui uma chave primaria composta de multiplas chaves 
estrangeiras implementa um relacionamento n:n entre as entidades cor- 
respondentes as tabelas referenciadas pelas chaves estrangeiras. Um 
exemplo de tabela deste tipo e a tabela Currie que tern como chave pri- 
maria CodCr e CodDisc. Ambas colunas sao chave estrangeira em rela- 
gao as tabelas Curso e Disciplina respectivamente. Portanto, a tabela 
Currie representa um relacionamento entre as entidades correspondentes 
as tabelas CodCr e CodDisc. No exemplo, a unica tabela deste tipo e a 
tabela Currie. 

□ Regra 2: Toda chave primaria e uma chave estrangeira 

A tabela cuja chave primaria e toda ela uma chave estrangeira representa 
uma entidade que forma uma especializaqao da entidade correspondente 
a tabela referenciada pela chave estrangeira. Um exemplo de tabela deste 
tipo e a tabela Laboratorio que possui como chave primaria as colunas 
(CodPr,CodSI), as quais sao chave estrangeira da tabela de salas. A res- 
trict o de integridade referencial em questao especifica que uma linha na 
tabela de laboratories somente existe, quando uma linha com a mesma 
chave existir na tabela de salas. A nfvel de modelo ER, isso significa que 
uma ocorrencia da entidade laboratorio somente pode existir quando a 
correspondente ocorrencia da entidade sala existe, ou seja, significa que 
a entidade laboratorio e uma especializagao de sala. No exemplo, a unica 
tabela deste tipo e a tabela Laboratorio. 

□ Regra 3: Demais casos 

Quando a chave primaria da tabela nao for composta de multiplas cha- 
ves primarias (regra 1 acima), nem for toda uma chave estrangeira (regra 
2 acima), a tabela representa uma entidade. Exemplificando, a tabela 
Curso, cuja chave primaria, a coluna CodCr nao contem chaves estran- 
geiras, representa uma entidade. Da mesma forma, a tabela Sala tambem 
representa uma entidade. Sua chave primaria (colunas CodPr e CodSI) 
contem apenas uma chave estrangeira (coluna CodSI). Assim, nao obe- 
dece ao requisito da multiplicidade de chaves estrangeiras (regra 1), nem 
o requisito de toda chave primaria ser estrangeira (regra 2) e enquadra- 


se na presente regra. O mesmo e valido para as tabelas Disciplina, Predio 
e Turma. 

Tendo feita a classificagao de tabelas segundo a composigao da chave 
primaria e com isso identificado as construgSes de ER correspondentes a cada 
tabela, e possfvel montar um diagrama ER inicial, conforme mostra a Figura 
5.19. 



Figura 5.19: Diagrama ER inicial para o BD academico 

5.3.2 ldentifica<;ao de relacionamentos l:n ou 1:1 

Toda chave estrangeira que nao se enquadra nas regras 1 e 2 acima, ou seja, 
toda chave estrangeira que nao faz parte de uma chave primaria composta 
por multiplas chaves estrangeiras, nem e toda ela uma chave primaria, repre- 
senta um relacionamento l:n ou 1:1. Em outros termos, toda chave estrangeira 
que nao corresponde a um relacionamento n:n, nem a uma entidade especiali- 
zada representa um relacionamento l:n ou 1:1. A regra nao permite definir se 
a cardinalidade do relacionamento e l:n ou 1:1. Para definir qual dos dois ti- 
pos de relacionamentos esta sendo representado pela chave estrangeira, e ne- 
cessario verificar os possiveis conteudos do banco de dados. No caso do 
exemplo, as chaves estrangeiras que representam relacionamentos l:n ou 1:1 
sao as seguintes: 


Tabeia Sala 

CodPr referencia Predio 
Tabeia Turma 

CodDisc referencia Disciplina 
(CodPr, CodSI) referencia Sala 

Com isso podemos completar a definicao dos relacionamentos no dia 
grama ER, conforme mostra a Figura 5.20. No caso do exemplo, todos relacio 
namentos referentes as chaves estrangeiras acima sao do tipo l:n. 



Figura 5.20: Definigao dos relacionamenfos 1 :n e 1:1 


5.3.3 Defini$ao de a tributes 


capacidade sigl a nome codigo 



Figura 5.21 : Definigao dos atributos 

Nesta etapa, para cada coluna de uma tabela, que nao seja chave estrangeira, 
e definido um atributo na entidade/relacionamento correspondente a tabela. 
Observe-se que colunas chave estrangeira nao correspondem a atributos no 
diagrama ER, mas sim a relacionamentos, e por isso ja foram tratadas nas eta- 
pas anteriores. Para o caso do exemplo, a execugao deste passo da engenharia 
reversa resulta no diagrama ER da Figura 5.21. 

5.3.4 Defini^do de identificadores de entidades 

No ultimo passo da engenharia reversa, sao definidos os identificadores das 
entidades e dos relacionamentos. A regra para definicao dos identificadores e 
a seguinte: 

□ Coluna da chave primaria que nao e chave estrangeira 

Toda coluna que faz parte da chave primaria e que nao e chave estran- 
geira corresponde a um atributo identificador da entidade ou relaciona- 
mento. 

□ Coluna da chave primaria que e chave estrangeira 

Toda coluna que faz parte da chave primaria e que e chave estrangeira 
corresponde a um identificador externo da entidade. Exemplificando, a 
coluna CodDisc, que e parte da chave primaria da tabela Turma e tarn- 


bem chave estrangeira em relagao a tabela Disciplina. Portanto, a enti- 
dade TURMA e identificada tambem pelo relacionamento com 
DISCIPLINA. 

Executando este passo da engenharia reversa sobre o modelo do exem- 
plo chegamos a Figura 5.22. 


capacidade sigl a nome codigo 



Figura 5.22: Definigao dos identificadores de entidades 

Exercicios 

Exercicio 5.1: Considere as seguintes alternativas de implementagao de um 
banco de dados relational: 

Alternativa 1: 

Aluno ( CodAl .Nome.CodCurso.Endereco) 

Alternativa 2 

Aluno ( CodAl .Nome.CodCurso) 

EnderecoAluno ( CodAI .Endereco) 

CodAI referenda Aluno 

Em ambos casos esta sendo representado um conjunto de alunos e informa- 
goes (codigo, nome, codigo de curso, enderego) a ele referentes. Discuta a luz 
dos printipios que baseiam as regras de tradugao de diagramas ER para mo- 
delo relational, qual das duas alternativas e prefertvel. 


Exercfcio 5.2: Usando as regras de transformagao de modelos ER para modelo 
logico relacional apresentadas neste capftulo, projete um BD relacional para o 
modelo ER da Figura 5.23. Para nao sobrecarregar o diagrama os atributos das 
entidades sao listados abaixo. Os atributos identificadores estao sublinhados. 
Produto ( Numero , NomeComercial, TipoEmbalagem, Quantidade, 
Pregollnitario) 

Fabricante ( CGC ,Nome,Endereco) 

Medicamento(Tarja, Formula) 

Perfumaria(Tipo) 

Venda(Data, NumeroNota ,NomeCliente,CidadeCliente) 

PerfumariaVenda(Quantidade,lmposto) 

MedicamentoReceitaVenda(Quantidade,lmposto) 

ReceitaMedica( CRM, Numero , Data) 

Exercfcio 5.3: Usando as regras de transformagao de modelos ER para modelo 
logico relacional apresentadas neste capftulo, projete um BD relacional para o 
modelo ER da Figura 5.24. Para nao sobrecarregar o diagrama os atributos das 
entidades sao listados abaixo. Os atributos identificadores estao sublinhados. 
Escritorio ( Numero , Local) 

Cliente ( NumeroCartMotorista, EstadoCartMotorista , Nome, Enderego, 
Telefone) 

Contrato aluguel ( Numero , Data, Duragao) 

Veiculo ( Numero , DataProximaManutengao, Placa) 

Tipo de Veiculo ( Codigo , Nome, ArCondicionado) 

Automovel (NumeroPortas, DiregaoFlidraulica, CambioAutomatico, Radio) 
Onibus (NumeroPassageiros, Leito, Sanitario) 



Figura 5.23: Modelo ER para uma farmacia 



Figura 5.24: Modelo ER para locadora de veiculos 

Exercicio 5.4: Abaixo e apresentado um esquema logico de um BD relacional 
que armazena dados sobre produtos em uma industria. Usando as regras de 
engenharia reversa apresentadas acima, construa um diagrama ER para este 
BD. 


Produto ( CodiaoTipoProd.NumeroProd .DescricaoProd.PrecoProd) 
CodigoTipoProd referenda TipoProd 
/* tabela de produtos de uma loja - CodigoTipoProd e o codigo do tipo 
do produto, NumeroProd e seu codigo, DescripaoProd e uma descripao 
do produto e PrepoProd e seu prepo */ 

Similaridade ( CodigoTipoProd, NumeroProd, 
CodiqoTipoProdSim.NumeroProdSim ) 

(CodigoTipoProd, NumeroProd) referencia Produto 
(CodigoTipoProdsim,NumeroProdSim) referencia Produto 

/* tabela de similaridade de produtos - para cada produto, informa quais sao 
seus produtos similares*/ 

TipoProd ( CodigoTipoProd , DescricaoTipoProd) 

/* tabela de tipos de produtos, com codigo e descripao */ 

Venda ( NumeroNF .DataVenda,CodReq,CodEmp) 

(CodigoReg) referencia Registradora 
(CodEmo) referencia Empregado 


/* tabela que informa as vendas que ocorreram na loja - informa o nu- 
mero da nota fiscal, a data da venda, a registradora na qual ocorreu, bem 
como o empregado que a realizou */ 

ItemVenda ( NumeroNF.CodiqoTipoProd.NumeroProd . 
Qtdeltem.Prepoltem) 

(NumeroNF) referenda Venda 
(CodigoTipoProd,NumeroProd) referenda Produto 
/* tabela com informa os itens de uma venda, isto e, que produtos e em 
que quantidade e com que prego foram vendidos em uma venda */ 

Registradora ( CodReq , SaldoReg) 

/* tabela com codigo e saldo de cada registradora na loja */ 

Empregado ( CodEmp , NomeEmp, SenhaEmp) 

/* tabela com codigo, nome e senha de cada empregado da loja */ 

Exerctcio 5.5: Abaixo e apresentado um esquema logico de um BD relacional 
que armazena dados genealogicos. Usando as regras de engenharia reversa 
apresentadas acima, construa um diagrama ER para este BD. 

Pessoa ( PessID , PessNome, NascLocID, DataNasc, FalecLocID, 
DataFalec, ProfID, FilhoCasamID, Sexo) 

NascLocID referenda Local 
FalecLocID referenda Local 
ProfID referenda Profiss 
FilhoCasamID referenda Casam 

/* Tabela de pessoas: content o identificador da pessoa, seu nome, local 
(identificador) e data de nascimento, local (identificador) e data de fale- 
cimento, profissao, identificador do casamento que gerou a pessoa e 
sexo */ 

Local ( LoclD .Cidade.Pais) 

/* Tabela de locais */ 

Profiss ( ProfID . ProfNome) 

/* Tabela de profissoes */ 

Casam ( CasamID . MaridoPessID, EsposaPessID, DataCasam, 
CasamLocID) 

MaridoPessID referenda Pessoa 
EsposaPessID referenda Pessoa 
CasamLocID referenda Local 

/* Tabela de casamentos: content identificador do casamento, identifica- 
dor do marido, identificador da esposa, data do casamento e local (iden- 
tificador) */ 
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Capitulo 

6 

Engenharia reversa 
de arquivos e 
normalizagao 


No Capitulo 5, foi apresentado um processo de engenharia reversa de modelos 
relacionais, que permite obter um modelo conceitual para um modelo logico 
relacional. 

Neste capitulo, sera vista a engenharia reversa de arquivos. Este processo 
permite obter um modelo logico relacional a partir do modelo logico de um 
banco de dados nao relacional. Ele permite que se execute a engenharia 
reversa de qualquer conjunto de dados para os quais se disponha de uma 
dcscricao, como documentos, arquivos manuais, arquivos convencionais em 
computador ou bancos de dados gerenciados por SGBD nao relacional. 

Como base teorica para este processo sera usado o conceito de 
normalizagao, uma tecnica que objetiva eliminar redundances de dados de ar- 
quivos. 

Ao final do capitulo, sao apresentados varios exercicios que compoem 
dois estudos de caso de engenharia reversa de dois sistemas, um de 
preparacao de congressos e outro de controle de um almoxarifado. 



6.1 INTRODUQAO 

Um percentual significative) dos sistemas de informacao hoje usados foram 
desenvolvidos ao longo dos ultimos vinte anos e nao utilizam bancos de da- 
dos relacionais. Sao os chamados sistemas legados (" legacy systems”). Os dados 
destes sistemas estao armazenados em arquivos de linguagens de terceira ge- 
ragao, como Basic, COBOL, MUMPS e outras, ou entao em bancos de dados 
da era pre-relacional, como IMS, ADABAS, DMS-II e os SGBD do tipo 
CODASYL (IDMS, IDS/2,...). Raramente, os arquivos destes sistemas estao 
documentados atraves de modelos conceituais. Alem disso, muitos dos ban- 
cos de dados relacionais existentes, principalmente em micro-computadores, 
nao possuem documentacao na forma de modelo conceitual. 

No entanto, ha situacoes no ciclo de vida de um sistema nas quais um 
modelo conceitual pode ser de grande valia. 

Um exemplo e a manutencao rotineira de software de um sistema de in- 
formacoes. Neste caso, o modelo conceitual pode ser usado como documenta- 
gao abstrata dos dados durante discussbes entre usuarios, analistas e progra- 
madores. A existencia de um modelo conceitual permite que pessoas que nao 
conhecam o sistema possam aprender mais rapidamente o seu funciona- 
mento. 

Outro exemplo no qual e importante possuir o modelo conceitual de um 
banco de dados ja implementada e o da migragao do banco de dados para 
uma nova plataforma de implementagao, por exemplo usando um SGBD rela- 
cional. A disponibilidade de uma documentacao abstrata, na forma de um 
modelo conceitual dos dados do sistema existente, pode acelerar em muito o 
processo de migragao, pois permite encurtar a etapa de modelagem de dados 
da novo banco de dados. 

O presente capitulo mostra como executar o processo de engenharia re- 
versa de arquivos convencionais ou de banco de dados pre-relacionais. 

6.2 VlSAO GERAL DO PROCESSO DE ENGENHARIA REVERSA 

A Figura 6.1 apresenta uma visao geral do processo de engenharia re versa de 
arquivos convencionais. 

O processo parte das descricoes dos arquivos que compSem o sistema 
existente. 

O primeiro passo e a representacao da descrigao de cada arquivo exis- 
tente na forma de um esquema de uma tabela relacional nao-normalizada. 
Este primeiro passo objetiva obter uma descricao independente do tipo de ar- 
quivo que esta sendo utilizado. A partir dai, o processo trabalha apenas com 
tabelas relacionais, o que o torna independente do tipo de arquivo que esta 
sendo usado como entrada ao processo de normalizagao. 



DER 

do sistema 


eliminapao de 
redundances 


DER 

do sistema 


transformap ao 
em ER 


modelo relacional integrado 



modelo 
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modelo relacional 
nao normalizado (1) 



modelo 

relacional normalizado (2) 



modelo relacional 
nao normalizado (2) 


representapao 
„como tabela NhL 


representapao' 
como tabela NN . 


descripao de arguivo existente (1) descripao de arguivo existente (2) 


Figura 6.1: Visao geral do processo de engenharia reversa 

A seguir, este esquema de tabela nao-normalizada passa por um pro- 
cesso conhecido por normolizagao, atraves do qual e obtido um modelo relaci- 
onal, contendo as descricoes das tabelas correspondentes ao arquivo em 
questao. O objetivo do processo de normalizacao e': 

□ Reagrupar informagbes de forma a eliminar redundancias de dados que 
possam existir nos arquivos. 

□ Reagrupar informacoes de uma forma que permita a obtencao de um mo- 
delo ER. 

Uma vez normalizados todos arquivos do sistema, os diferentes esque- 
mas relacionais obtidos pela normalizacao sao integrados, gerando o esquema 
relacional do banco de dados do sistema. Nesta etapa, as informacoes comuns 
a diferentes arquivos sao identificadas e representadas uma unica vez. 



Finalmente, a partir do esquema relacional assim obtido, usando as re- 
gras para engenharia reversa de um modelo relacional mostradas no capftulo 
anterior, e possfvel obter o modelo ER do sistema existente. 

6.3 Documento Exemplo 

O processo de normalizacao pode ser executado sobre qualquer tipo de repre- 
sentacao de dados. Pode partir da descricao de um arquivo em computador, 
do "lay-out" de um relatorio ou de uma tela, etc. Para exemplificar o processo 
de normalizacao que e descrito abaixo usamos um documento (Figura 6.2), 
que poderia fazer parte de um sistema de gerencia de projetos. 

Para cada projeto, sao informados o codigo, a descricao e o tipo do pro- 
jeto, bem como, os empregados que atuam no projeto. Ja para cada empre- 
gado do projeto, sao informados o seu numero, nome e categoria funcional, 
bem como a data em que o empregado foi alocado ao projeto e o tempo pelo 
qual o empregado foi alocado ao projeto. A Figura 6.2 apresenta um exemplo 
de possfvel conteudo deste documento. 

RELATORIO DE ALOCAQAO A PROJETO 


CODIGO DO PROJETO : LSC001 


TIPO : Novo Desenv. 

DESCRIQAO : Sistema de Estoque 




CODIGO DO 

NOME 

CATEGORIA 

S ALAR 10 

DATA DE 

TEMPO 

EMPREGADO 


FUNCIONAL 


INICIO NO 

ALOCADO 





PROJETO 

AO 






PROJETO 

2146 

Joao 

A1 

4 

1/11/91 

24 

3145 

Silvio 

A2 

4 

2/10/91 

24 

6126 

Jose 

B1 

9 

3/10/92 

18 

1214 

Carlos 

A2 

4 

4/10/92 

18 

8191 

Mario 

A1 

4 

1/11/92 

12 

CODIGO DO PROJETO : PAG02 


TIPO: 

Manutengao 

DESCRIQAO : Sistema de 

RH 




CODIGO DO 

NOME 

CATEGORIA 

S ALAR 10 

DATA DE 

TEMPO 

EMPREGADO 


FUNCIONAL 


INICIO NO 

ALOCADO 





PROJETO 

AO 






PROJETO 

8191 

Mario 

A1 

4 

1/05/93 

12 

4112 

Joao 

A2 

4 

4/01/91 

24 

6126 

Jose 

B1 

9 

1/11/92 

12 


Figura 6.2: Exemplo de documento a ser normalizado 

6.4 Representaqao na forma de tabela nao normalizada 

O primeiro passo do processo de engenharia reversa consta em transformar a 
descricao do documento ou arquivo a ser normalizado em um esquema de 
uma tabela relacional. A Figura 6.3 apresenta a tabela correspondente ao do- 
cumento da Figura 6.2. Essa tabela e dita nao-normalizada (ou mais precisa- 



mente nao-primeira-forma-normal ) pois possui uma tabela aninhada. Usaremos a 
abreviatura NN para identificar esta forma de representar a tabela. Uma tabela 
aninhada (tambem chamada por outros autores de grupo repetido ou coluna 
multi-valorada ou ainda coluna ndo atomica ) e uma coluna que ao inves de con- 
fer valores atomicos, contem tabelas aninhadas. 

tabela nao-normalizada 
tabela que contem outras tabelas aninhadas 


No caso da Figura 6.3, na coluna Emp, aparece, para cada linha de de- 
partamento, uma tabela aninhada, que contem os dados dos empregados refe- 
rentes ao departamento em questao. O conceito de tabela aninhada e o cor- 
respondente, na abordagem relacional, aos conceitos de vetor ou "array" de 
linguagens como Pascal ou de item de grupo repetido (especificado com clau- 
sula "OCCURS") da linguagem COBOL. 


CodProj 

Tipo 

Descr 



Emp 







CodEmp 

Nome 

Cat 

Sal 

Datalni 

TempAI 

LSC001 

Novo Desenv. 

Sistema de 

2146 

J oao 

A1 

4 

1/11/91 

24 



Estoque 

3145 

S ilvio 

A2 

4 

2/10/91 

24 




6126 

J ose 

B1 

9 

3/10/92 

18 




1214 

Carlos 

A2 

4 

4/10/92 

18 




8191 

Mario 

A1 

4 

1/11/92 

12 

PAG02 

Manutengao 

Sistema de 

8191 

Mario 

A1 

4 

1/05/93 

12 



RH 

4112 

J oao 

A2 

4 

4/01/91 

24 




6126 

J ose 

B1 

9 

1/11/92 

12 


Figura 6.3: Documento exemplo na forma de tabela nao normalizada 

A tabela da Figura 6.3 pode ser descrita pelo seguinte esquema de tabela 
relacional: 

Proj (CodProj, Tipo, Descr, 

( CodEmp , Nome, Cat, Sai, Datalni, TempAI)) 

No esquema acima, foi usada uma extensao da notagao de esquema re- 
lacional apresentada no capitulo 5. A extensao consta do uso de parenteses 
aninhados para descrever tabelas aninhadas. No caso de tabelas aninhadas, as 
colunas sublinhadas indicam a coluna ou grupo de colunas que servem para 
distinguir diferentes linhas da tabela aninhada referente a uma linha da tabela 
de seu nivel externo. Assim, a coluna CodProj distingue as linhas (cada uma 
referente a um projeto) da tabela Proj. Ja a coluna CodEmp, serve para distin- 
guir diferentes linhas de empregado dentro do grupo referente a um projeto. 

Para apresentar um outro exemplo de representagao nao normalizada de 
documentos, mostramos na Figura 6.4 e na Figura 6.5 a defini^ao de um 
arquivo que contem dados de alunos usando a notagao de Pascal e de COBOL 
respectivamente. 



type reg_aluno= record 
cod_al: integer; 
nome_al: char_60; 

ingressos_cursos_al: array [1 ..10] of record 
cod_curso: integer; 
semestrejngresso: integer 

end; 

disciplinas_cursadas_al: array [0..200] of record 
cod_disc: integer; 

semestres_cursados: array [1 ..20] of record 
semestre_disc: integer; 
nota_disc: integer 

end 

end 

end; 

arq_aluno= file of reg_aluno; 

Figura 6.4: Registro de aluno (Pascal) 

FD Arq-Alunos 
01 Reg-AI. 

03 Cod-AI 
03 Nome-AI 

03 Ingr-Cursos-al OCCURS 1 TO 10 
05 Cod-Curso 
05 Sem-ingresso 
03 Disc-Curs-AI OCCURS 0 to 200 
05 Cod-Disc 

05 Sem-Cursado OCCURS 1 TO 20 
07 Sem-Disc-Cursada 
07 Nota-Disc 

Figura 6.5: Registro de aluno (COBOL) 

O arquivo contem dados referentes a alunos de uma universidade. Cada 
registro contem informacoes referentes a um aluno. O registro do aluno con- 
tem seu codigo, seu nome, uma lista de ingressos em cursos e uma lista de 
disciplinas cursadas. A lista de ingressos em curso contem o codigo do curso 
em que o aluno ingressou junto com o semestre de ingresso no curso. A lista 
de disciplinas cursadas contem uma entrada para cada disciplina que o aluno 
cursou. Para cada disciplina cursada e informado seu codigo, junto com os 
diversos semestres em que o aluno cursou a disciplina. Para cada semestre e 
informado o semestre e a nota que o aluno obteve na disciplina no semestre 
em questao. 

Para o arquivo em questao, a representagao nao normalizada seria a se- 
guinte: 



Arq-Alunos ( Cod-AI , Nome-AI, 

( Cod-Curso , Sem-ingresso) 

( Cod-Disc, 

( Sem-Disc-Cursada , Nota-Disc))) 

Observe que as descrigoes de arquivos nao fornecem as colunas que sao 
chave primaria, ja que este conceito nao esta presente nas linguagens referi- 
das. Cabe observar ainda que na representagao nao normalizada nao sao as- 
sociados nomes as tabelas aninhadas, ja que estes nao sao necessarios para o 
processo de engenharia reversa. 

6.5 Normauzaqao 

Obtido o esquema relacional correspondente ao documento, passa-se ao pro- 
cesso de normalizagao. Este processo baseia-se no conceito de forma normal. 
Uma forma normal e uma regra que deve ser obedecida por uma tabela para 
que esta seja considerada "bem projetada". Ha diversas formas normais, isto 
e, diversas regras, cada vez mais rigidas, para verificar tabelas relacionais. No 
caso deste trabalho, vamos considerar quatro formas normais. As formas 
normais sao denominadas simplesmente primeira, segunda, terceira e quarta 
forma normal, abreviadamente 1FN, 2FN, 3FN e 4FN 

6.5.1 Passagem a primeira forma normal (1 FN) 

O proximo passo da normalizagao consta da transformagao do esquema de 
tabela nao normalizada em um esquema relacional na primeira forma normal 
(1FN). Uma tabela encontra-se na 1FN quando nao contem tabelas aninhadas. 
Portanto, a passagem a 1FN consta da eliminagao das tabelas aninhadas 
eventualmente existentes. 

primeira forma normal (1FN) 

diz-se que uma tabela esta na primeira 
forma normal, quando ela nao contem 
tabelas aninhadas 


Para transformar um esquema de tabela nao-normalizada em um es- 
quema na 1FN ha duas altemativas: 

□ Construir uma unica tabela com redundancia de dados 

Cria-se uma tabela na qual os dados das linhas externas a tabela aninhada 
sao repetidos para cada linha da tabela aninhada. No caso da tabela da 
Figura 6.3, o esquema resultante seria o seguinte: 

ProjEmp (CodProj, Tipo, Descr, CodEmp, Nome, Cat, Sal, Datalni, TempAI) 
Nesta tabela, os dados do projeto aparecem repetidos para cada linha da 
tabela de empregados. 

□ Construir uma tabela para cada tabela aninhada 

Cria-se uma tabela referente a propria tabela que esta sendo normalizada e 
uma tabela para cada tabela aninhada. No caso da tabela da figura 7.4, o 
esquema resultante seria o seguinte: 



Proj (CodProj, Tipo, Descr) 

ProjEmp (CodProj, CodEmp, Nome, Cat, Sal, Datalni, TempAI) 

Considerando apenas a corregao do processo de normalizagao, a pri- 
meira alternativa (tabela unica) e a preferida. Ao decompor uma tabela em 
varias tabelas, como ocorre na segunda alternativa, podem ser perdidas rela- 
tes entre informagSes. 

Entretanto, para fins praticos, preferimos a segunda alternativa ( decom - 
posigdo de tabelas), mesmo sabendo que ela pode levar a modelos imperfeitos. 
A motivagao e de ordem pratica. No caso de uma tabela nao normalizada, 
como a do exemplo, que possui apenas uma tabela aninhada, fica facil visua- 
lizar a tabela na 1FN, na primeira alternativa. Entretanto, quando houver di- 
versas tabelas aninhadas, eventualmente com diversos niveis de aninha- 
mento, fica diffcil visualizar a tabela na 1FN. 

Para verificar o tipo de problema que pode ser causado pela decomposi- 
gao em varias tabelas, o leitor pode estudar o Exercfcio 6.16. 

Na decomposigao de tabelas, a passagem a primeira forma normal por 
decomposigao de tabelas e feita nos seguintes passos: 

1 E criada uma tabela na 1FN referente a tabela nao normalizada e que con- 
tem apenas as colunas com valores atomicos, isto e, sem as tabelas ani- 
nhadas. A chave primaria da tabela na 1FN e identica a chave da tabela 
nao normalizada. 

2 Para cada tabela aninhada, e criada uma tabela na 1FN composta pelas 
seguintes colunas: 

• a chave primaria de cada uma das tabelas na qual a tabela em ques- 
tao esta aninhada 

• as colunas da propria tabela aninhada 

3 Sao definidas as chaves primarias das tabelas na 1FN que correspondem a 
tabelas aninhadas. 

Conforme mencionado, no caso da tabela exemplo, a decomposigao gera 
duas tabelas com o seguinte esquema: 

1FN 

Proj ( CodProj , Tipo, Descr) 

ProjEmp ( CodProj, CodEmp . Nome, Cat, Sal, Datalni, TempAI) 

O conteudo destas tabelas, caso considerarmos o conteudo do docu- 
mento original que esta sendo normalizado, e apresentado na Figura 6.6. 

Observe a tabela ProjEmp. Esta tabela refere-se a tabela aninhada con- 
tida na tabela nao normalizada de partida. Ela contem as seguintes colunas: 

O Coluna CodProj, que e a chave primaria da tabela nao normalizada ex- 
terna a tabela aninhada em questao. 

O Colunas da tabela aninhada em questao. 

Ja a chave primaria da tabela ProjEmp e composta pelas colunas CodProj 
e CodEmp. Isto ocorre pelo fato de o mesmo empregado poder trabalhar em 
multiplos projetos. Assim, na tabela ProjEmp aparecem multiplas linhas para 
um mesmo empregado e e necessario usar o codigo do projeto para distinguir 
entre elas. 


Proj: 


CodProj 

Tipo 

Descr 

LSC001 

Novo Desenv. 

Sistema de Estoque 

PAG02 

Manutengao 

Sistema de R H 


ProjEmp: 


CodProj 

CodEmp 

Nome 

Cat 

Sal 

Datalni 

TempAI 

LSC001 

2146 

J oao 

A1 

4 

1/11/91 

24 

LSC001 

3145 

Silvio 

A2 

4 

2/10/91 

24 

LSC001 

6126 

J ose 

B1 

9 

3/10/92 

18 

LSC001 

1214 

Carlos 

A2 

4 

4/10/92 

18 

LSC001 

8191 

Mario 

A1 

4 

1/11/92 

12 

PAG02 

8191 

Mario 

A1 

4 

1/05/93 

12 

PAG02 

4112 

J oao 

A2 

4 

4/01/91 

24 

PAG02 

6126 

J ose 

B1 

9 

1/11/92 

12 


Figura 6.6: Tabelas referentes ao exemplo na 1 FN 

Cabe observar que, caso cada empregado trabalhasse em um unico pro- 
jeto apenas, a chave primaria seria composta apenas pela coluna CodEmp. 
Neste caso, a coluna Cod Proj nao faria parte da chave primaria e seria apenas 
uma das colunas nao chave da tabela em questao. 

Neste ponto do processo de normalizagao, pode ser dificil encontrar 
nomes adequados para as tabelas. No caso do exemplo, os nomes das tabelas 
foram inspirados nas chaves primarias das tabelas. Assim, a segunda tabela, 
que tern como chave primaria as colunas CodProj e NumEmp foi denominada 
ProjEmp. Como os nomes das tabelas nao sao relevantes ao processo de nor- 
malizagao, a recomendagao e estabelecer os nomes definitivos das tabelas 
apenas ao final da normalizagao. 

Um outro exemplo de passagem a primeira forma normal e o do arquivo 
de alunos visto acima (Figura 6.4 e Figura 6.5). Conforme mostrado acima, sua 
representagao nao normalizada e a seguinte: 

NN 

Arq-Alunos ( Cod-AI , Nome-AI, 

( Cod-Curso , Sem-ingresso) 

( Cod-Disc, 

( Sem-Disc-Cursada , Nota-Disc))) 

Como esta tabela NN contem tres tabelas aninhadas ela gerara quatro 
tabelas na 1FN (tantas tabelas quantos abre parenteses aparecem na forma 
NN). Na 1FN as tabelas, ainda sem a chave primaria, sao as seguintes: 


1FN 

Alunos (Cod-AI, Nome-AI) 

AlunoCurso (Cod-AI, Cod-Curso, Sem-ingresso) 

AlunoDisc (Cod-AI, Cod-Disc) 

AlunoDiscSem (Cod-AI, Cod-Disc, Sem-Disc-Cursada, Nota-Disc) 

A primeira tabela corresponde a tabela NN sem suas tabelas aninhadas. 
Ja a tabela AlunoCurso na 1FN corresponde a primeira tabela aninhada na 
forma NN. Observe que esta tabela contem, alem das colunas CodCurso e 
Sem-ingresso, tambem a coluna Cod-AI, chave primaria da tabela na qual a 
tabela aninhada encontra-se na forma NN. 


Pelo mesmo motivo, a tabela AlunoDiscSem, que corresponde a terceira 
tabela aninhada, contem as colunas Cod-AI e Cod- Disc. Estas sao as chaves 
primarias das tabelas nas quais a tabela aninhada em questao encontra-se na 
forma NN. 


AlunoCurso 

AlunoDisc 

AlunoDiscSem 


As chaves primarias das tabelas na 1FN sao as seguintes: 

1FN 

Alunos ( Cod-AI . Nome-AI) 

( Cod-AI, Cod-Curso , Sem-ingresso) 

( Cod-AI. Cod-Disc ) 

( Cod-AI, Cod-Disc, Sem-Disc-Cursada , Nota-Disc) 
Conforme ja foi mencionado acima, a chave primaria de uma tabela na 
1FN nao necessariamente e a concatenagao das chaves primarias das colunas 
chaves primarias na forma NN. Abaixo apresentamos um exemplo em que, ao 
contrario dos exemplos ate agora mostrados, a chave primaria da tabela na 
1FN nao e a concatenagao das chaves das tabelas na forma NN. Considere a 
tabela nao normalizada apresentada abaixo. 

NN 


Arq-Candidatos ( Cod-Curso , Nome-Curso, Numero-Vagas-Curso, 

( Cod-Cand , Nome-Cand, Escore-Cand)) 

Esta tabela representa um arquivo que armazena informagSes sobre um 
concurso vestibular. O arquivo contem um registro para cada curso, com co- 
digo, nome e niimero de vagas do curso. Alem disso para cada curso ha uma 
lista dos candidatos aprovados no curso. Supoe-se que cada candidato tenha 
sido aprovado em um curso somente. 

A passagem a 1FN gera as tabelas abaixo: 

1FN 

Cursos ( Cod-Curso , Nome-Curso, Numero-Vagas-Curso) 

Candidatos (Cod-Curso, Cod-Cand , Nome-Cand, Escore-Cand) 

Observe que na segunda tabela, correspondente a tabela aninhada da 
forma NN, a chave primaria e apenas a coluna Cod-Cand (codigo do candi- 
dato), ja que um candidato pode aparecer uma vez somente no arquivo. 

De forma geral, para determinar a chave primaria de uma tabela na 1FN 
que corresponda uma tabela aninhada na forma NN deve-se proceder como 
segue: 


1. Tomar como parte da chave primaria da tabela na 1FN a chave primaria 
da tabela NN. 

2. Verificar se esta chave primaria e suficiente para identificar as linhas da 
tabela na 1FN. 

• Caso seja suficiente, a chave primaria da tabela na 1FN e a mesma 
que a da tabela aninhada na forma NN. 

• Caso contrario, deve-se determinar quais as demais colunas que 
sao necessarias para identificar as linha da tabela na 1FN, com- 
pondo assim a chave primaria na 1FN. 

6.5.2 Dependencia funcional 

Para entender as duas formas normais que serao apresentadas a seguir e ne- 
cessario compreender o conceito de dependencia funcional. 

Em uma tabela relacional, diz-se que uma coluna C 2 depende funcional- 
mente de uma coluna Ci (ou que a coluna Ci determina a coluna C 2 ) quando, 
em todas linhas da tabela, para cada valor de Ci que aparece na tabela, apa- 
rece o mesmo valor de C 2 . 

O conceito fica mais facil de se entender, se considerarmos um exemplo. 



Codigo 


Salario 



El 


10 



E3 


10 



El 


10 



E2 


5 



E3 


10 



E2 


5 



El 


10 



Figura 6.7: Extrato de tabela com dependencia funcionais 

A tabela da Figura 6.1 contem, entre outras colunas irrelevantes ao 
exemplo, as colunas Codigo e Salario. Diz-se que a coluna Salario depende fun- 
cionalmente da coluna Codigo (ou que a coluna Codigo determina a coluna 
Salario) pelo fato de cada valor de Codigo estar associado sempre ao mesmo 
valor de Salario. Exemplificando o valor “El ” da coluna Codigo identifica 
sempre o mesmo valor de Salario (“1 0”). 

Para denotar esta dependencia funcional, usa-se uma expressao na 
forma Codigo — > Salario. A expressao denota que a coluna Salario depende 
funcionalmente da coluna Codigo. Diz-se que a coluna Codigo e o determi- 
nante da dependencia funcional. 

De forma geral, o determinante de uma dependencia funcional pode ser 
um conjunto de colunas e nao somente uma coluna como na definigao acima. 
Exemplificando, na tabela da Figura 6.8, a coluna C depende das colunas A 
e B. 


A 

B 

C 

D 

B 

5 

2 

20 

C 

4 

2 

15 

B 

6 

7 

20 

B 

5 

2 

20 

C 

2 

2 

15 

C 

4 

2 

15 

A 

10 

5 

18 

A 

12 

3 

18 

A 

10 

5 

18 

B 

5 

2 

20 

C 

4 

2 

15 

A 

10 

5 

18 

C 

4 

2 

15 


Dependences funcionais: 

(A,B) -> 0 

D 

Figura 6.8: Tabela com exemplos de dependencies funcionais 

6.5.3 Passagem a segunda forma normal (2FN) 

A passagem a segunda forma normal (2FN) objetiva eliminar um certo tipo de 
redundancia de dados. Para exemplificar, tomamos a tabela ProjEmp da 
Figura 6.6. Nesta tabela, os dados referentes a empregados (Nome, Cat e Sal) 
estao redundantes, para os empregados que trabalham em mais de um pro- 
jeto. Um exemplo e o do empregado de codigo “81 91 ”. A passagem a segunda 
forma norma objetiva eliminar este tipo de redundancia de dados. 

Uma tabela encontra-se na segunda forma normal (2FN) quando, alem 
de encontrar-se na primeira forma normal, cada coluna nao chave depende da 
chave primaria completa. Uma tabela que nao se encontra na segunda formal 
contem dependencias funcionais parciais, ou seja, contem colunas nao chave que 
dependem apenas de uma parte da chave primaria. 

segunda forma normal (2FN) 

uma tabela encontra-se na segunda forma 
normal, quando, alem de estar na 1FN, nao 
contem dependencias parciais 


Obviamente, uma tabela que esta na 1FN e que possui apenas uma co- 
luna como chave primaria nao contem dependencias parciais, ja que nesta ta- 
bela e impossivel uma coluna depender de uma parte da chave primaria, visto 
que a chave primaria nao e composta por partes (por diversas colunas). As- 
sim, toda tabela que esta na 1FN e que possui apenas uma coluna como chave 



primaria ja esta na 2FN. O mesmo aplica-se para uma tabela que contenha 
apenas colunas chave primaria. 

No caso do documento exemplo, a tabela Proj encontra-se na 2FN por 
possuir uma chave primaria simples (composta de apenas uma coluna). 

Ja a tabela ProjEmp deve ser examinada para procurar dependences 
parciais, pois possui uma chave primaria composta de mais de uma coluna. 
As colunas Nome, Cat e Sal dependem, cada uma, apenas da coluna 
NumEmp, ja que nome, categoria funcional e salario sao determinados tao 
somente pelo numero do empregado. Por sua vez, as colunas Datalni e 
TempAI dependem da chave primaria completa (para determinar a data em 
que um empregado comegou a trabalhar em um projeto, bem como para de- 
terminar o tempo pelo qual ele foi alocado ao projeto e necessario conhecer 
tanto o codigo do projeto quanto o numero do empregado). 

Tabela na 1FN e dependences funcionais 


ProjEmp ( 


CodProi, 

CodEmo 


1 


i 


Nome, Cat, Sal, Datalni, TempAI ) 

AAA 


Tabeias na 2FN e dependences funcionais 



Emp ( 


CodEmp, 


Nome, Cat, Sal ) 


A A 


Figura 6.9: Passagem a 2FN 



Para passar a 2FN, isto e, para eliminar as dependences de parte da 
chave primaria e necessario dividir a tabela ProjEmp em duas tabelas com o 
seguinte esquema: 

ProjEmp ( CodProi, CodEmp . Datalni, TempAI) 

Emp ( CodEmp . Nome, Cat, Sal) 

O processo de passagem a 2FN e ilustrado na Figura 6.9. 

Assim o modelo relacional correspondente ao arquivo em questao, na 
2FN e o seguinte. 

2FN 

Proj ( CodProi , Tipo, Descr) 

ProjEmp ( CodProi, CodEmp . Datalni, TempAI) 

Emp ( CodEmp . Nome, Cat, Sal) 

O conteudo das tabelas na 2FN, caso considerarmos o conteudo do do- 
cumento original que esta sendo normalizado, e apresentado na Figura 6.10. 

De forma mais precisa, o processo de passagem da 1FN a 2FN e o se- 
guinte. 

□ Copiar para a 2FN cada tabela que tenha chave primaria simples ou que 
nao tenha colunas alem chave. No caso do exemplo, e o que acontece com 
a tabela Proj. 

□ Para cada tabela com chave primaria composta e com pelo menos uma 
coluna nao chave (no exemplo, a tabela ProjEmp): 

• Criar na 2FN uma tabela com as chaves primarias da tabela na 1FN 
(no exemplo, trata-se da tabela ProjEmp na 2FN) 

• Para cada coluna nao chave fazer a seguinte pergunta: 

"a coluna depende de toda a chave ou de apenas parte dela?" 

Caso a coluna dependa de toda a chave (as colunas Datalni e TempAI 
da tabela ProjEmp) o 

0 Criar a coluna correspondente na tabela com a chave com- 
pleta na 2FN (a coluna Datalni e TempAI da tabela ProjEmp 
na 2FN) 

Caso a coluna dependa apenas de parte da chave (as colunas Nome, 
Sal e Cat da tabela ProjEmp na 2FN) 

0 Criar, caso ainda nao existir, uma tabela na 2FN que tenha 
como chave primaria a parte da chave que e determinante da 
coluna em questao (a tabela Emp na 2FN). 

0 Criar a coluna dependente dentro da tabela na 2FN (as colu- 
nas Nome, Sal e Cat da tabela Emp na 2FN). 


Proj: 


CodProj 

Tipo 

Descr 

LSC001 

Novo Desenv. 

Sistema de Estoque 

PAG02 

Manutenpao 

Sistema de RH 


ProjEmp: 


CodProj 

CodEmp 

Datalni 

TempAI 

LSC001 

2146 

1/11/91 

24 

LSC001 

3145 

2/10/91 

24 

LSC001 

6126 

3/1 0/92 

18 

LSC001 

1214 

4/1 0/92 

18 

LSC001 

8191 

1/11/92 

12 

PAG02 

8191 

1/05/93 

12 

PAG02 

4112 

4/01/91 

24 

PAG02 

6126 

1/11/92 

12 


Emp: 


CodEmp 

Nome 

Cat 

Sal 

2146 

Joao 

A1 

4 

3145 

Silvio 

A2 

4 

6126 

Jose 

B1 

9 

1214 

Carlos 

A2 

4 

8191 

Mario 

A1 

4 

8191 

Mario 

A1 

4 

4112 

Joao 

A2 

4 

6126 

Jose 

B1 

9 


Figura 6.10: Tabelas referentes ao exemplo na 2FN 

6.5.4 Passagem a terceira forma normal (3FN) 

Na passagem a terceira forma normal, elimina-se um outro tipo de redundan- 
cia. Para exemplificar, vamos considerar a tabela Emp da Figura 6.10. Vamos 
supor que o salario (coluna Sal) de um empregado seja determinado pela sua 
categoria funcional (coluna Cat). Neste caso, a inform a gao de que salario e 
pago a uma categoria funcional esta representado redundantemente na tabela, 
tantas vezes quantos empregados possui a categoria funcional. A passagem a 
3FN objetiva eliminar este tipo de redundancia de dados. 

Uma tabela encontra-se na 3FN quando, alem de estar na 2FN, toda co- 
luna nao chave depende diretamente de chave primaria, isto e, quando nao ha 
dependences funcionais transitivas ou indiretas. 


terceira forma normal (3FN) 

uma tabela encontra-se na terceira forma 
normal, quando, alem de estar na 2FN, nao 
contem dependences transitivas 

Uma dependencia funcional transitiva ou indireta acontece quando uma 
coluna nao chave primaria depende funcionalmente de outra coluna ou com- 
binacao de colunas nao chave primaria. A passagem a 3FN consta em dividir 
tabelas de forma a eliminar as dependence transitivas. O processo de passa- 
gem a 3FN para o exemplo e mostrado na Figura 6.11. 


Tabela na segunda forma normal (2FN) 
depend^nciatransitiva 


Emp ( 


CodEmp . 


Nome, Cat, Sal ) 


Tabelas na terceira forma normal (3FN) 



Emp ( CodEmp . Nome, Cat ) 



Figura 6.1 1 : Passagem a 3FN para o exemplo 

Com isso, na 3FN, o modelo referente ao documento sendo normalizado 
e o seguinte. 

3FN 

Proj ( CodProi , Tipo, Descr) 

ProjEmp ( CodProi, CodEmp . Datalni, TempAI) 

Emp ( CodEmp . Nome, Cat) 

Cat (Cat, Sal) 

As tabelas referentes a terceira forma normal do documento exemplo 
tern seu conteudo mostrado na Figura 6.12. 




CodProj 

Tipo 

Descr 

LSC001 

Novo Desenv. 

Sistema de 



Estoque 

PAG02 

Manutengao 

Sistema de RH 


ProjEmp: 


CodProj 

NumEmp 

Datalni 

TempAI 

LSC001 

2146 

1/11/91 

24 

LSC001 

3145 

2/10/91 

24 

LSC001 

6126 

3/1 0/92 

18 

LSC001 

1214 

4/1 0/92 

18 

LSC001 

8191 

1/11/92 

12 

PAG02 

8191 

1/05/93 

12 

PAG02 

4112 

4/01/91 

24 

PAG02 

6126 

1/11/92 

12 


Emp: 


NumE 

mp 

Nome 

Cat 

2146 

Joao 

A1 

3145 

Silvio 

A2 

6126 

Jose 

B1 

1214 

Carlos 

A2 

8191 

Mario 

A1 

8191 

Mario 

A1 

4112 

Joao 

A2 

6126 

Jose 

B1 


Cat: 



Figura 6.12: Tabelas referentes ao exemplo na 3FN 

De forma mais precisa, o processo de passagem da 2FN a 3FN e o se- 
guinte: 

□ Copiar para o esquema na 3FN cada tabela que tenha menos que duas 
colunas nao chave, pois neste caso nao ha como haver dependences tran- 
sitivas. 

□ Para tabelas com duas ou mais colunas nao chave: 

a) Criar uma tabela no esquema da 3FN com a chave primaria da ta- 
bela em questao. 

b) Para cada coluna nao chave fazer a seguinte pergunta: 

"a coluna depende de alguma outra coluna nao chave (dependencia transi- 
tiva ou indireta)?" 


Caso a coluna dependa apenas da chave O 

* Copiar a coluna para a tabela na 3FN 
Caso a coluna depender de outra coluna O- 

* Criar, caso ainda nao exista, uma tabela no esquema na 3FN 
que tenha como chave primaria a coluna da qual ha a de- 
pendence indireta. 

* Copiar a coluna dependente para a tabela criada. 

* A coluna determinante deve permanecer tambem na tabela 
original. 

6.5.5 Passagem a quarta forma normal 

Para a maioria dos documentos e arquivos, a decomposigao ate a 3FN e sufi- 
ciente para obter o esquema de um banco de dados correspondente ao docu- 
mento. Na literatura aparecem outras formas normals, como a forma normal 
de Boyce /Codd, a 4FN e a 5FN. Destas a unica que tern importance na pra- 
tica da engenharia reversa e a quarta forma normal (4FN). 

Para explicar a 4FN vamos utilizar um exemplo. Suponha que alguem 
tenha projetado um banco de dados relacional para o DER da Figura 6.13. 
Neste DER o relacionamento UTILIZAQAO indica que deseja-se manter a in- 
formagao de que empregado usa que equipamento em que projeto. 



Figura 6.13: Exemplo de DER para utilizagao de equipamentos 

Caso seja projetada um banco de dados relacional para este exemplo 
usando as regras de projeto mostradas no capltulo anterior, o esquema do 
banco de dados contera quatro tabelas. Tres tabelas servirao para implemen- 
tar as entidades. Uma quarta tabela: 

Util ( CodProi.CodEmp.CodEquip ) 

servira para implementar o relacionamento. 

Agora suponha que os requerimentos da aplicagao tenham mudado. O 
DER que representa os novos requerimentos e o apresentado na Figura 6.14. 
Como se observa, a granulosidade das informagSes que o usuario deseja 
manter nao e mais tao grande como no caso da Figura 6.13. Agora deseja-se 


saber que equipamento e usado em que projeto (relacionamento Proj-Eq) e 
deseja-se saber que empregado esta alocado a que projeto (relacionamento 
Proj_Emp). A inform a^ao de que equipamento e usado por que empregado 
passa a ser uma informagao derivada: um empregado pode usar todos equi- 
pamentos alocados aos projetos dos quais ele participa. 



Figura 6.14: Exemplo da utilizagao de equipamentos - nova versao 

Continuando o exemplo, vamos supor que o banco de dados projetada 
para o relacionamento ternario nao tenha sido modificado, apesar da existen- 
cia de novos requerimentos. Vamos verificar como ficaria o conteudo da ta- 
bela UTILIZAQAO neste caso (Figura 6.15). 

A tabela da Figura 6.15 obviamente contem redundancia de dados. 
Exemplificando, a informagao de que os empregados {“1”,”2”,”3”} trabalham 
no projeto “1” esta representada duas vezes na tabela. Isso ocorre, porque 
para cada equipamento usado no projeto e necessario informar todos seus 
empregados. A conseqiiencia e que tambem a informagao de que equipa- 
mentos sao usados em um projeto esta armazenada redundantemente. Exem- 
plificando, o fato de o projeto “1” usar os equipamentos {“1”,”2”} esta repre- 
sentada tres vezes, ja que o projeto conta com tres empregados. 

Entretanto, se verificarmos a tabela contra as formas normais vistas ate 
este ponto, observa-se que a tabela encontra-se na 3FN. Esta na 1FN por nao 
conter tabelas aninhadas, esta na 2FN por nao possuir colunas nao chave (as 
tres colunas compSem a chave) e esta na 3FN pela mesma razao. 

Para evitar este tipo de redundancia de dados, e necessario considerar 
uma outra forma normal, a quarta forma normal (4FN). Esta forma normal ba- 
seia-se no conceito de dependencia funcional multi-valor ada. 

Uma coluna ou conjunto de colunas depende multi-valoradamente de 
uma coluna (determinante) da mesma tabela quando um valor do atributo 
determinante identifica repetidas vezes um conjunto de valores na coluna de- 
pendente. No caso do exemplo (ver Figura 6.16), a coluna CodEmp depende 
multi-valoradamente da coluna CodProj, ja que um valor de CodProj (por 
exemplo “1”) determina multiplas vezes um conjunto de valores de CodEmp 


(no caso o conjunto de empregados do projeto, {“1 ”,”2”,”3”}, que aparece duas 
vezes). 


CodProj 

CodEmp 

CodEquip 

1 

1 

1 

1 

2 

1 

1 

3 

1 

1 

1 

2 

1 

2 

2 

1 

3 

2 

2 

2 

2 

2 

2 

4 

3 

3 

1 

3 

4 

1 

3 

3 

3 

3 

4 

3 

3 

3 

5 

3 

4 

5 

4 

2 

5 


Figura 6.15: Tabela que implementa o relacionamento UTILIZAQAO 



Figura 6.16: Dependencia funcional multi-valorada 

Para representar uma dependencia funcional multi-valorada usa-se 
uma expressao semelhante a usada para representar dependences funcionais 
simples substituindo a seta simples por uma seta dupla. Na tabela 
UTILIZAQAO, ha as seguintes dependences: 

CodProj CodEmp 

CodProj CodEquip 

Uma tabela esta na 4FN caso, alem de estar na 3FN, nao possua mais 
que uma dependencia funcional multi-valorada. Portanto, a tabela 
UTILIZAQAO nao esta na 4FN e deve ser decomposta em duas tabelas: 
ProjEmp ( CodProj, CodEmp ) 

ProjEquip ( CodProj, CodEquip ) 



quarta forma normal (4FN) 


uma tabela encontra-se na quarta forma 
normal, quando, alem de estar na 3FN, nao 
contem dependences multi-valoradas 


Estas tabelas correspondem a implementacao dos dois relacionamentos 
da Figura 6.14. Estas tabelas, no caso do exemplo, teriam o conteudo mos- 
trado na Figura 6.17. 


ProjEmp: 


CodProj 

CodEmp 

1 

1 

1 

2 

1 

3 

2 

2 

3 

3 

3 

4 

4 

2 


ProjEquip: 


CodProj 

CodEquip 

1 

1 

1 

2 

2 

2 

2 

4 

3 

1 

3 

3 

3 

5 

4 

5 


Figura 6.17: Tabelas do exemplo na 4FN 

6.5.6 Problemas da normaliza^ao 

Nesta secao vamos discutir alguns problemas que podem aparecer na pratica 
da normalizacao de arquivos. 

6.5.6. 1 Chaves primarias omitidas ou incorretas 

Em arquivos convencionais, o conceito de chave primaria nao e obrigatorio, 
como ocorre na abordagem relational. Assim, e posstvel encontrar arquivos 
que nao possuem chave primaria. Quando um arquivo conventional nao pos- 
sui chave primaria ou quando a chave primaria nele usada difere da usual na 
organizagao, deve-se proceder como se a chave primaria aparecesse no ar- 
quivo, isto e, deve-se inseri-la na forma NN. 




Exemplificando, em um arquivo com dados sobre empregados de uma 
organizagao enviado para fins de fiscalizagao a um orgao governamental, 
pode estar omitido o identificador de empregado usado na organizagao, ja 
que este e irrelevante para o orgao fiscalizador. 

Uma variante da situagao descrita e a de documentos nos quais uma 
chave primaria e propositadamente omitida, por nao ser relevante para os 
leitores do arquivo. Um exemplo e apresentado no documento do Exercicio 
6 . 5 . 

Outra situagao analoga e o uso de uma chave alternativa, ao inves da 
chave primaria usual do arquivo. Exemplificando, no caso mencionado acima, 
se o orgao governamental fosse a receita federal, o arquivo poderia ter como 
chave primaria o CIC do empregado, ao inves da chave primaria normal- 
mente usada na organizagao. 

Em ambos os casos, se a normalizagao fosse executada diretamente so- 
bre o arquivo convencional, apareceriam tabelas espurias, com chaves prima- 
rias diferentes das usadas para as entidades representadas. Assim, tao logo 
uma destas situagoes seja detectada, deve-se introduzir, ja na forma NN, a 
chave primaria usual da tabela, como se ela aparecesse no arquivo normali- 
zado. 

6.5. 6.2 Atributos relevantes implicitamente representados 

Atributos podem aparecer em arquivos convencionais de forma implicita, na 
forma de ordenacao de registros ou de listas, na forma de ponteiros fisicos, 
etc. Quando esta situagao ocorrer, deve-se proceder como se o atributo apare- 
cesse explicitamente no documento. 

Um exemplo e o da ordenagao de registros ou elementos de listas, onde 
a propria ordem e uma informagao relevante. Para exemplificar, vamos reto- 
mar o exemplo do concurso vestibular apresentado acima, agora com uma 
modificagao. Na nova versao, nao existe mais a coluna Escore-Cand, que 
continha a nota do aluno. Consideramos agora que os alunos aparecem orde- 
nados no registro do curso, de acordo com sua classificagao no vestibular. Se- 
guindo os passos usuais da normalizagao, a tabela na forma NN seria a se- 
guinte. 

NN 

Arq-Candidatos ( Cod-Curso , Nome-Curso, Numero-Vagas-Curso, 

( Cod-Cand , Nome-Cand)) 

O processo de normalizagao desta tabela resultaria nas seguintes tabelas: 

4FN 

Cursos ( Cod-Curso , Nome-Curso, Numero-Vagas-Curso) 

Candidatos (Cod-Curso, Cod-Cand , Nome-Cand) 

Como na abordagem relacional linhas nao estao ordenadas, a informa- 
gao da classificagao dos candidatos em um curso foi perdida no processo de 
normalizagao. Assim, o procedimento correto teria sido o de incluir explici- 
tamente na tabela ja na forma NN (coluna Ordem-Cand) a informagao que 
aparece implicitamente no arquivo na forma da ordenacao dos registros. A 
tabela na forma NN que resultaria neste caso e a apresentada a seguir. 


NN 

Arq-Candidatos ( Cod-Curso , Nome-Curso, Numero-Vagas-Curso, 

( Cod-Cand , Nome-Cand,Ordem-Cand)) 

Outro exemplo de atributo implicitamente representado e o caso do uso 
de apontadores ou referencias fisicas a registros. Estes apontadores devem ser 
substituidos, quando da passagem a forma NN, pela chave primaria do ar- 
quivo que esta sendo referenciado. 

6.5. 6.3 Atributos irrelevantes, redundantes ou derivados 

Arquivos convencionais podem confer atributos que nao sao relevantes do 
ponto de vista conceitual e que existem no arquivo por questoes tecnicas ou 
de performance da implementacao em questao. Exemplos deste tipo de atri- 
butos sao campos com o numero de ocorrencias de listas, com o tamanho de 
outros campos, com estampas de tempo, etc. Este campos devem ser elimina- 
dos ja quando da passagem a forma nao normalizada. 

6.6 INTEGRAQAO DE MODELOS 

A normalizacao de cada um dos arquivos ou documentos de um sistema con- 
duz a defi nicao de um conjunto de tabelas. O passo seguinte da engenharia 
reversa e o de integrar os modelos obtidos para cada arquivo no modelo global 
do banco de dados (ver Figura 6.1). Esse processo e conhecido na literatura de 
banco de dados por integragao de visdes ou integragao de esquemas. 

Esse processo tern dois objetivos: 

d) Os atributos de uma mesma entidade (ou de um mesmo relacionamento) 
podem estar armazenados em diferentes arquivos. Apos o processo de 
normalizacao, estes atributos aparecem como colunas em diferentes tabe- 
las. O processo de integracao de visoes objetiva juntar estas tabelas em 
uma unica tabela que representa a entidade ou relacionamento em ques- 
tao. 

e) O processo de normalizacao garante que cada tabela, se considerada isola- 
damente, esteja livre de redundancias de dados. Entretanto, certos casos 
de redundancias de dados entre tabelas podem ainda permanecer e devem 
ser eliminados durante o processo de integracao de visdes. 

O processo de integracao de modelos da-se em tres passos: (1) integra- 
cao de tabelas com a mesma chave, (2) integracao de tabelas com chave con- 
tida e (3) verificacao de 3FN. A seguir cada um destes tres passos e descrito 
em detalhe. 

6.6.1 Integracao de tabelas com mesma chave 

O processo de integracao de modelos inicia pela juncao de tabelas que pos- 
suem a mesma chave primaria. Aqui quando falamos de "mesma" chave pri- 
maria estamos exigindo que os dominios e os conteudos das colunas que 
compoem a chave primaria sejam iguais. Quando isso ocorrer, as diferentes 
tabelas devem ser juntadas em uma unica tabela no modelo global. 

Para exemplificar retomamos o sistema de gerencia de projetos mos- 
trado acima. O documento cuja normalizacao foi apresentada resultou no 
modelo relacional abaixo. 



Documento 1: 

Proj ( CodProi , Tipo, Descr) 

ProjEmp ( CodProi, CodEmp , Datalni, TempAI) 

Emp ( CodEmp . Nome, Cat) 

Cat (Cat, Sal) 

Vamos considerar ainda que um outro documento tenha sido normali- 
zado, resultando no modelo relacional abaixo. 

Documento2: 

Proj ( CodProi , Datalnicio, Descr, CodDepto) 

Depto ( CodDepto , NomeDepto) 

ProjEquipamento ( CodProi, CodEquipam , Datalni) 

ProjEmp ( CodProi, CodEmp . FungaoEmpProj) 

Equipamento ( CodEquipam , Descrigao) 

Caso a coluna Cod Proj tenha o mesmo valor nas tabelas Proj dos dois 
modelos, estas duas tabelas devem ser juntadas no modelo global. Observe 
que a coluna Tipo e proveniente do documento 1, as colunas Datalnicio e 
CodDepto sao provenientes do documento 2 e a coluna Descr e proveniente 
de ambos documentos. 

Da mesma forma, caso as colunas Cod Proj e CodEmp tenham os mes- 
mos valores nas tabelas ProjEmp de ambos modelos, estas duas tabelas devem 
ser fundidas em uma unica tabela. 

O modelo global resultante da integragao dos dois modelos acima e o 
seguinte. 

Modelo integrado: 

Proj ( CodProi , Tipo, Descr, Datalnicio, CodDepto) 

ProjEmp ( CodProi, CodEmp . Datalni, TempAI, FungaoEmpProj) 

Emp ( CodEmp . Nome, Cat) 

Cat (Cat, Sal) 

Depto ( CodDepto , NomeDepto) 

ProjEquipamento ( CodProi, CodEquipam , Datalni) 

Equipamento ( CodEquipam , Descrigao) 

Como se ve no exemplo, todo processo de integragao de modelos baseia- 
se na comparagao dos nomes de colunas e de tabelas dentro dos diferentes 
modelos. Nesta comparagao, podem aparecer dois tipos de conflitos de nomes. 
Homdnimos ocorrem quando dois diferentes objetos aparecem sob o mesmo 
nome. Por exemplo, diferentes campos, como data de nascimento e data de 
admissao de empregado aparecem em dois modelos diferentes sob o mesmo 
nome DataEmp. Sindnimos ocorrem quando um mesmo objeto aparece sob di- 
ferentes nomes. Por exemplo, a coluna descrigao de projeto aparece em um 
modelo sob o nome DescrigaoProj e outra vez sob o nome TituloProj. 

Conflitos de nomes sao resolvidos atraves de renomeagao. Infelizmente, 
nao ha ainda tecnicas na literatura que resolvam de forma sistematica o pro- 
blema do conflito de nomes. Assim, resolugao deste conflito continua depen- 
dendo muito da experiencia e do conhecimento do modelador. 


6.6.2 lntegra$ao de tabelas com chaves contidas 

Uma outra situagao na qual tabelas sao fundidas e aquela na qual uma tabela 
contem somente a chave primaria e a chave primaria e subconjunto da chave 
primaria de outra tabela. Note que, novamente, quando f alamos de uma 
chave primaria estar contida dentro da outra, estamos exigindo que a chave 
primaria tenha o mesmo dominio e os mesmos valores. 

Como exemplo vamos considerar as duas tabelas abaixo mostradas. 

AlunoDisc ( Cod-AI, Cod-Disc ) 

AlunoDiscSem ( Cod-AI, Cod-Disc, Sem-Disc-Gursada , Nota-Disc) 

Vamos considerar que a primeira tabela informa que um aluno cursou 
uma disciplina, enquanto que a segunda tabela informa a nota obtida pelo 
aluno em uma disciplina em um semestre. Neste caso, as colunas Cod-AI e 
Cod-Disc da tabela AlunoDisc contem exatamente os mesmos valores que as 
colunas Cod-AI e Cod-Disc da tabela AlunoDiscSem. As informagoes contidas 
na tabela AlunoDisc ja estao na tabela AlunoDiscSem. Portanto, a tabela 
AlunoDisc e redundante e pode ser eliminada sem perda de informagSes. 

Observe que, para integrar uma tabela em outra estamos exigindo que a 
tabela contenha somente a chave primaria. Para exemplificar um caso em que 
esta exigencia nao e cumprida, vamos considerar as duas tabelas abaixo. A 
primeira tabela informa se um aluno teve ou nao bolsa de estudos em um se- 
mestre, enquanto que a segunda informa a nota obtida pelo aluno em uma 
disciplina cursada em um semestre. Consideramos que as colunas Cod-AI e 
Sem- Disc da tabela AlunoSem contenham exatamente os mesmos valores que 
as colunas Cod-AI e Sem-Disc da tabela AlunoDiscSem. 

AlunoSem ( Cod-AI. Sem-Disc . BolsaSimNao) 

AlunoDiscSem ( Cod-AI. Cod-Disc, Sem-Disc . Nota-Disc) 

Neste exemplo, a tabela AlunoSem nao deve ser integrada a tabela 
AlunoDiscSem, pois, apesar da chave primaria da primeira tabela estar con- 
tida na chave primaria da segunda tabela, a primeira possui atributos nao 
chave. Se o atributo BolsaSimNao fosse incluido na segunda tabela, a infor- 
magao da obtengao ou nao de bolsa por um estudante apareceria multiplas 
vezes no banco de dados, tantos quantas disciplinas o aluno cursou no se- 
mestre. 

Um outro caso no qual a integragao das tabelas nao deve ser feita, e 
quando os valores das colunas chave primaria nao sao iguais, apesar de pos- 
suirem os mesmos nomes e dominios. Como exemplo, vamos considerar as 
tabelas abaixo. 

AlunoMatric ( Cod-AI. Sem-Disc ) 

AlunoDiscSem ( Cod-AI. Cod-Disc, Sem-Disc . Nota-Disc) 

Neste exemplo, consideramos que a primeira tabela (AlunoMatric) repre- 
senta o fato de o aluno estar matriculado em um semestre. A segunda tabela 
(AlunoDiscSem) representa a nota que o aluno obteve em uma disciplina em 
um semestre. Podem haver estados do banco de dados, em que um aluno 
aparece associado a um semestre na tabela AlunoMatric, sem que exista infor- 
magao sobre este aluno /semestre na tabela AlunoDiscSem. Este seria o estado 
do banco de dados durante o semestre letivo, quando um aluno ja esta matri- 


culado, mas ainda nao obteve notas. Neste caso, a primeira tabela nao pode 
ser eliminada, pois contem informagSes que nao aparecem na segunda tabela. 

6.6.3 Volta d2FN 

A integragao de dois modelos, que caso considerados isoladamente estao na 
4FN, pode conduzir a um modelo que esta na 2FN mas nao na 3FN. 

Consideremos os modelos abaixo, ambos obtidos a partir de diferentes 
arquivos: 

Arquivo 1 : 

Departamento ( CodDepto . NomeDepto, CodGerenteDepto) 

Arquivo 2: 

Departamento ( CodDepto . LocalDepto, NomeGerenteDepto) 

A integragao destes dois modelos resultaria no modelo integrado abaixo 
mostrado. 

Modelo integrado: 

Departamento ( CodDepto . NomeDepto, CodGerenteDepto, 

LocalDepto, NomeGerenteDepto) 

No modelo integrado, a tabela Departamento encontra-se na 2FN, mas 
nao na 3FN, se considerarmos que uma coluna nao chave 
(NomeGerenteDepto) depende funcionalmente de outra coluna nao chave 
(CodGerenteDepto). 

O problema ocorrido e que o Arquivo 2 referencia o gerente de um de- 
partamento nao atraves da chave primaria de gerentes (que e seu codigo) mas 
atraves do nome do gerente. Esse e mais um exemplo das conseqiiencias da 
omissao de chaves primarias em arquivos convencionais, que havia sido ci- 
tado acima. 

Assim, deve-se, apos a integragao de modelos, verificar as tabelas, afim 
de garantir que todas estejam efetivamente na 3FN. 

6.7 CONSTRUQAO DO MODELO ER E EUMINAQAO DE REDUNDANCES 

Apos a integragao dos modelos obtidos a partir dos diversos arquivos e do- 
cumentos normalizados, segue a construgao do modelo ER (ver Figura 6.1). 
Nesta construgao usam-se as regras apresentadas no capitulo anterior para 
transformagao de modelos relacionais em modelos ER. 

6.8 Verificaqao do modelo ER - Limitaqoes da Normalizaqao 

O processo de normalizagao nao conduz necessariamente a um modelo ER 
perfeito. A normalizagao apenas elimina campos multi-valorados e elimina 
redundances de dados detectadas pelas formas normais descritas. 

Conforme mencionado, na Segao 6.5.1, aqui optamos pela altemativa de 
decompor tabelas na passagem a 1FN. Esta alternativa, apesar de mais sim- 
ples de tratar na pratica pode levar a imperfeigoes no modelo (ver exemplo no 
Exercicio 6.16). 

Alem das formas normais aqui descritas, outras foram propostas na lite- 
ratura, como a forma normal de Boyce-Codd e a quinta forma normal (ver re- 
ferencias bibliografica ao final do Capitulo). Como estas formas normais tra- 


tam de casos que aparecem pouco frequentemente na pratica, preferimos nao 
apresenta-las neste texto. 

Assim, o ultimo passo da engenharia reversa e a verificagao do mo- 
delo ER obtido, procurando corrigir imperfeicoes ainda existentes. Para ver 
exemplos de alguns tipos de problemas que podem permanecer no modelo 
normalizado, o leitor pode estudar os exemplos de engenharia reversa que 
aparecem nos exercicios a seguir, particularmente os referentes ao sistema de 
preparagao de congressos e ao sistema de controle do almoxarifado. 

Exercicios 

A lista de exercicios abaixo contem dois estudos de caso de engenharia re- 
versa do banco de dados de um sistema a partir de describes de documentos 
e de arquivos convencionais. Um sistema e o sistema de preparagao de con- 
gressos da IFIP que foi apresentado no Exercicio 3.9. A ele referem-se os exer- 
cicios Exercicio 6.3 ate Exercicio 6.11. O outro sistema e o sistema de controle 
de um almoxarifado que foi apresentado no Exercicio 3.10. A ele referem-se 
os exercicios Exercicio 6.12 ate Exercicio 6.21. Para resolver estes exercicios e 
recomendavel que o leitor tenha lido a descrigao do respectivo sistema no Ca- 
pitulo 3. 

Exercicio 6.1: Considere a tabela abaixo 

ItemVenda ( NumeroNF.CodiqoTipoProd.NumeroProd , DescricaoProd 
DataVenda, CodReg, CodEmp, 
Qtdeltem,Pregoltem,NomeEmp, DescricaoTipoProd) 

O significado das colunas acima e aquele apresentado no Exercicio 5.4. 
A tabela apresentada esta na primeira forma normal. Apresente a segunda e 
terceira formas normais. 

Exercicio 6.2: No contexto de um sistema de controle academico, considera a 
tabela abaixo: 

Matricula 

( CodAluno.CodTurma .CodDisciplina.NomeDisciplina.NomeAluno. 

CodLocalNascAluno,NomeLocalNascAluno) 

As colunas possuem o seguinte significado: 

CodAiuno - codigo do aluno matriculado 

CodTurma - codigo da turma na qual o aluno esta matriculado (codigo e o 
identificador de turma) 

CodDisciplina - codigo que identifica a disciplina da turma 
NomeDisciplina - nome de uma disciplina da turma 
NomeAIuno - nome do aluno matriculado 

CodLocalNascAluno - codigo da localidade em que nasceu o aluno 
NomeLocalNascAluno - nome da localidade em que nasceu o aluno 
Verifique se a tabela obedece a segunda e a terceira forma normais. Caso 
nao obedega, iaqa as transformagSes necessarias 
Exercicio 6.3: (refere-se ao sistema de preparagao de congressos descrito no 
Exercicio 3.9) A Figura 6.18 apresenta uma lista todos artigos submetidos a 
um congresso. 


No cabe^alho, aparece o codigo e o nome do congresso. A seguir, sao 
listados os codigos e nomes dos GTs que promovem o congresso. Apos, em 
varias colunas sao listados o codigo do artigo, seu titulo, seu assunto 
principal, seu codigo de autor e os codigos e nomes dos varios autores do 
artigo. Observar que o mesmo codigo de artigo pode aparecer em diferentes 
congressos, ja que a numeragao de artigos inicia em um em cada congresso 
diferente. 

Execute a normalizacao do documento, mostrando cada uma das formas 


normals. 



Rela^ao de artigos submetidos ao 
congresso 

Congresso: DB25 — Advances in Database 
Systems 

GTs promo tores: GT3.1 - Database 


Systems 

GT3.3 

Conceptual Modeling 


Database 


Codigo 

Tftulo do 

Assunto 

Codigo 

Nome do 

do 

artigo 

principal 

do autor 

autor 

artigo 





1 

Semantic Integration in 

Heteregoneous 

2 

Wen-Suan Li 


Heteregoeneous Databases 

Databases 

4 

Chris Clifton 

2 

Providing Dynamic Security in a 

Heteregoneous 

21 

N.B. Idris 


Federated Database 

Databases 

7 

W.A. Gray 




32 

R.F. Chuchhouse 

3 

Efficient and effective clustering 

Spatial databases 

12 

Raymond R. Ng 


methods 


14 

Jiawei Han 

4 

Automated Performance Tuning 

Performance and 

36 

Kurt. P. Brown 



Optimization 



5 

Bulk Loading into an OODB 

Object oriented 

1 

Janet L. Wiener 



databases 




Congresso: 0003 — Object Oriented 

Modeling 

GTs promotores: GT4.6 - Software 

Engineering 

Codigo Tftulo do Assunto 

do artigo principal 

artigo 

1 Temporal aspects in 00 models Temporal 

modeling 


Codigo Nome do 

do autor autor 

2 Wen-Suan Li 


Figura 6.18: Lista de artigos submetidos aos congressos 

Exercicio 6.4: (refere-se ao sistema de preparagao de congressos descrito no 
Exercicio 3.9) A Figura 6.19 apresenta a definicao de um arquivo convencional 
que armazena dados dos artigos submetidos aos varios congressos. A defini- 
te* do artigo esta na linguagem COBOL, na qual muitos sistemas legados es- 
tao escritos. O leitor podera fazer este exercicio mesmo que nao conheca 
COBOL, apenas com base na explicates abaixo. 



Arquivo COBOL (artigos) 

FD ARQ-ARTIGOS. 

01 REG-ARTIGO. 

03 COD-CONGR 

03 NOME-CONGR 

03 NUMERO-ART 

03 TIT-ART 

03 NO-DE-AUTORES 

03 NO-DE-REVISORES 

03 NO-DE-TEMAS 

03 AUTOR OCCURS 1 TO 20 TIMES 

DEPENDING ON NO-DE-AUTORES. 

05 COD-AUTOR 
05 NOME-AUTOR 

03 TEMA OCCURS 1 TO 5 TIMES 

DEPENDING ON NO-DE-TEMAS. 

05 COD-TEMA 
05 NOME-TEMA 

03 REVISOR OCCURS 1 TO 5 TIMES 

DEPENDING ON NO-DE-REVISORES. 
05 COD-REVISOR 
05 NOME-REVISOR 
05 STATUS-REVISAO 


Figura 6.19: Arquivo COBOL que armazena os artigos submetidos 

O arquivo contem um registro para cada artigo submetido a congresso 
Lembre do exercicio precedente, que um artigo e identificado pelo codigo do 
congresso ao qual foi submetido e pelo seu codigo. A descrigao em COBOL 
nos informa que cada registro de artigo contem: o codigo do congresso, o 
nome do congresso, o codigo do artigo, o titulo do artigo, uma lista com os 
codigos e nomes dos diversos autores, uma lista com codigo e nome dos te- 
mas de que trata o artigo e uma lista com codigo, nome e status da revisao dos 
varios especialistas que estao julgando ou julgaram o artigo. As listas sao es- 
pecificadas em COBOL na forma de clausulas OCCURS. Os campos NO-DE- 
AUTORES, NO-DE-TEMAS e NO-DE-REVISORES apenas servem para con- 
trolar as respectivas listas de campos. Portanto, nao devem ser considerados 
na normalizagao, ja que sao redundantes (ver Segao 6. 5.6. 3). O campo de sta- 
tus da revisao pode conter dois valores diferentes e informa se o artigo ja re- 
cebeu parecer do revisor ou nao. 

Execute a normalizagao do documento, mostrando cada uma das formas 
normais. 

Exercicio 6.5: (refere-se ao sistema de preparagao de congressos descrito no 
Exercicio 3.9) A Figura 6.20 apresenta o programa de um congresso. 


DB25 — Advances in Database Systems 
Conference Program 

Monday September 12 

09:00-10:30 Registration 
10:00-10:45 Opening Ceremony 
10:45-11:00 Break 

11:00-12:30 Heterogeneous and Federated Databases (chair: Herve Gallaire) 
Semantic Integration in Heterogeneous Databases Using Neural 
Networks, Wen-Syan Li and Chris Clifton - USA 
Providing Dynamic Security Control in a Federated Database, N.B. 

Idris, W.A. Gray and R.F. Churchhouse - UK 
An approach for Building Secure Database Federations, Dirk Jonscher 
and Klaus R. Dittrich- Switzerland 
12:30-14:00 Lunch 

14:00-15:30 Issues on Architectures (Chair: Claudia Medeiros) 

Optimization A Igorithms for Erploiting the Parallelism- Communication 
Tradeoff in Pipelined Parallelism, Waqar Hasan and Rajeev 
Motwani USA 

Dali: A High Performance Main Memory Storage Manager, H.V. 
Jagadish, Daniel Lieuwen, Rajeev Rastogi, Avi Silberschatz and S. 
Sudarshan- USA 

Some Issues in Design of Distributed Deductive Databases, Mukesh K. 
Mohania and N.L. Sarda- India 
15:30-16:30 Break 

16:00-17:30 Performance and Optimization (Chair: Avi Silberschatz) 

Towards Automated Performance Tuning for Complex Workloads, Kurt 
P. Brown, Manish Mehta, Michael Carey and Miron Livny- USA 


Tuesday September 13 

09:00-10:30 Object Oriented Databases (chair: Malkolm Atkinson) 

Supporting Exceptions to Schema Consistency to Ease Schema Evolution 
in OODBMS, Eric Amiel, Maria-Jo Bellosta, Eric Dujardin and 
Eric Simon-France 


Figura 6.20: Programa de um congresso 

No cabeqalho constam o codigo e o nome do congresso. A seguir e listada a 
data a que se referem as informacoes seguintes (um congresso pode ocorrer 
em varios dias subsequentes). Apos sao listadas as seqoes que sao apresenta- 
das no dia. Lembre que uma seqao e um horario do congresso. Algumas se- 
qoes, como a cerimonia de abertura ("Opening Ceremony") ou o intervalo 
(break), nao tern apresentacao de artigos. Outras possuem apresentacao de 
artigos, que sao listados em ordem de apresentacao apos o titulo da segao. 
Esta seqoes possuem um moderador (chair) que aparece nomeado junto ao 
titulo da segao. 

Este documento exemplifica varios casos especiais que devem ser trata- 
dos na normalizagao. 



O documento omite varios codigos de entidades (ver Segao 6.5. 6.1), que 
nao sao importantes para seu leitor. Estao omitidos o codigo do artigo e os 
codigos das pessoas que aparecem no modelo (autor e moderador). 

Alem disso o documento apresenta de forma implfcita (ver Secao 6. 5.6. 2) 
a informacao da seqiiencia de apresentacao dos artigos em uma segao. 

Execute a normalizacao do documento, mostrando cada uma das formas 
normais. 

Exercfcio 6.6: (refere-se ao sistema de preparagao de congressos descrito no 
Exercfcio 3.9) A Figura 6.21 apresenta a carta de aceitagao de um artigo. Esta 
carta enviada para o autor principal do artigo. Portanto, ha uma carta por ar- 
tigo. Como cada artigo tern como identificador o codigo de seu congresso e 
seu codigo, estes dois campos sao tambem os identificadores de uma carta de 
aceitacao. Como no caso do exercfcio anterior, ha varias chaves primarias 
omitidas no documento. Deixamos ao leitor que as identifique e inclua na 
normalizacao. 

Execute a normalizacao do documento, mostrando cada uma das formas 
normais. 

Exercfcio 6.7: (refere-se ao sistema de preparacao de congressos descrito no 
Exercfcio 3.9) A Figura 6.22 apresenta a definicao de um arquivo convencional 
que armazena dados dos congressos. A definicao esta em COBOL. Valem aqui 
as mesmas observacoes que as feitas com referenda ao arquivo de artigos 
apresentado acima. 

Execute a normalizacao do documento, mostrando cada uma das formas 


normals. 
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questions about the conference or your participation, please contact the 
organizers at the address below. Alternatively, you can contact the IFIP 
representative in your country. 
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Yours sincerely 
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FD ARQ-CONGRESSO . 

01 REG-CONGRESSO . 

03 COD-CONG 

03 NOME-CONG 

03 DATA- INSC-CONG 

03 NO-DE-GTS 

03 NO-DE-INSCR 

03 GT OCCURS 1 TO 3 TIMES 

DEPENDING ON NO-DE-GTS. 

05 COD-GT 
05 NOME-GT 

03 INSCRITO OCCURS 0 TO 200 TIMES 
DEPENDING ON NO-DE-INSCR. 
05 COD-INSCR 
05 NOME - I NS CR 
05 PAiS-INSCR 


Figura 6.22: Arquivo COBOL de congressos 

Exercicio 6.8: Realize a integragao dos modelos referentes aos cinco docu- 
mentos e arquivos que voce normalizou nos exercicios precedentes. 

Exercicio 6.9: Identifique as chaves estrangeiras no modelo resultante da in- 
tegracao feita no exercicio anterior. 

Exercicio 6.10: Construa um diagrama ER a partir do modelo relacional ob- 
tido no Exercicio anterior. Utilize o processo de engenharia reversa descrito 
na Segao 5.3. 

Exercicio 6.11: Identifique as diferencas do modelo ER construido no exerci- 
cio anterior com o modelo ER construido no Exercicio 3.9. Comente a causa 
das diferencas. 

Lista de estoque em dd/mm/aa 
Corredor: (— NoCorredor-— ) 

Receptaculo Codigo da Peca Descricao Quantidade 

(— NoRecptac) (— CodPeca— ) (— DescricaoPeca— ) (—Quant—) 

(— NoRecptac) (—CodPeca—) (—DescricaoPeca—) (—Quant—) 


Corredor: (-NoCorredor-—) 


Receptaculo Codigo da Peca 

(—NoRecptac) (—CodPeca—) 
(—NoRecptac) (—CodPeca—) 


Descricao Quantidade 

(—DescricaoPeca— ) (—Quant— ) 
(—DescricaoPeca— ) (—Quant— ) 


Figura 6.23: Lista de estoque por corredor do almoxarifado 



Exercfcio 6.12: (refere-se ao sistema de controle de almoxarifado descrito no 
Exercfcio 3.10) A Figura 6.23 apresenta uma lista de estoque. Esta lista esta 
organizada por corredor e apresenta, para cada receptaculo, qual a pega ar- 
mazenada (codigo e descrigao), juntamente com a quantidade de unidades da 
pega estocadas no receptaculo. 

Execute a normalizagao do documento, mostrando cada uma das formas 
normals. 

FD LISTA-DISTRIB . 

01 REG-LISTA. 

03 COD-OC 

03 DATA-ENTREGA 

03 NO-ESTRADO 

03 NO-DE-CORREDORES 

03 COD-EMPLHADEIRA 

03 OPER-EMPILHADEIRA 

03 ITEM-CORR OCCURS 0 TO 20 TIMES 

DEPENDING ON NO-DE-CORREDORES. 


05 

NO 

-CORR 

05 

NO 

-DE- RECEPTACULOS 

05 

ITEM-RECEPT OCCURS 0 TO 5 TIMES 


DEPENDING ON NO-DE-RECETACULOS 


07 

NO-RECEPT 


07 

COD-PECA 


07 

DESCR-PECA 


07 

QTDE 


Figura 6.24: Lista de distribuigao 

Exercfcio 6.13: (refere-se ao sistema de controle de almoxarifado descrito no 
Exercfcio 3.10) A Figura 6.24 apresenta a estrutura de um arquivo COBOL 
que armazena as listas de distribuigao. Este arquivo registra, para cada en- 
trega, identificada pelo codigo da ordem de compra (COD-OC) e pela data da 
entrega, os seguintes dados: o numero do estrado que sera usada na distribui- 
gao, o codigo da empilhadeira a usar , o operador da empilhadeira e uma lista 
de itens que identificam os corredores a visitar durante a distribuigao. A lista 
informa, para cada corredor, quais os receptaculos que serao visitados e, para 
cada receptaculo qual o codigo e a descrigao da pega a armazenar, juntamente 
com a quantidade de unidades a colocar no receptaculo. 

Execute a normalizagao do documento, mostrando cada uma das formas 
normals. 

Ao Cliente 

(— codCIiente— ) (— nomeCliente— ) 


Informamos que seu pedido (— noPedido— ) estara sendo 
entregue na rampa (— noRampa— ) 


Figura 6.25: Boleto indicative de rampa de saida de pegas 


Exercicio 6.14: (refere-se ao sistema de controle de almoxarifado descrito no 
Exercicio 3.10) A Figura 6.25 mostra um boleto que e emitido para cada pe- 
dido feito por um cliente. Este boleto informa ao cliente em que rampa seu 
pedido sera entregue. 

Execute a normalizacao do documento, mostrando cada uma das formas 
normais. 

Situagao de atendimento de OCs pendentes em dd/mm/aa 

OC numero: (— noOC— ) Data da OC: (---data—) 

Codigo do Fornecedor: (— codFornec— ) 

Nome do Fornecedor: (—NomeFornec) 


Codigo 

Descrigao 

Quantidade Data 

Quantidade 

Pega 

Pega 

Pedida Entrega 

Entregue 

(...) 

(...) 

(— ) (—data—) 

(...) 



(—data—) 

(...) 



Total entregue: 

(...) 

(...) 

(...) 

(—) (—data—) 

(...) 



Total entregue: 

(...) 

(...) 

(...) 

(— ) (—data—) 

(...) 



(—data—) 

(...) 



(—data—) 

(...) 



Total entregue: 

(...) 

(...) 

(...) 

(...) 

Total entregue: 

0 

OC numero: (—noOC— 

) Data da OC: (—data—) 


Codigo do Fornecedor: 

(—codFornec—) 


Nome do Fornecedor: ( 

—NomeFornec) 


Codigo 

Descrigao 

Quantidade Data 

Quantidade 

Pega 

Pega 

Pedida Entrega 

Entregue 

(...) 

(...) 

(— ) (—data—) 

(...) 



(—data—) 

(...) 



Total entregue: 

(...) 


Figura 6.26: Situagao de atendimento de ordens de compra 

Exercicio 6.15: (refere-se ao sistema de controle de almoxarifado descrito no 
Exercicio 3.10) A Figura 6.26 apresenta a estrutura de um documento que lista 
a situagao de atendimento de ordens de compra (OC). Uma OC pode estar 
parcialmente atendida, isto e, para cada OC podem ocorrer entregas parciais 
(apenas algumas pecas, parte da quantidade). 



O documento lista em seu cabecalho o codigo da OC, sua data e seu for- 
necedor (codigo e nome). Para cada pega encomendada na OC, o documento 
lista o codigo, a descri^ao e a quantidade pedida. A seguir, para cada entrega 
e listada a data da entrega e a quantidade entregue. A soma da quantidade ja 
entregue e listada a seguir. Observe que certas pecas podem nao ter tido en- 
tregas. 

Exercicio 6.16: (refere-se ao sistema de controle de almoxarifado descrito no 
Exercicio 3.10) A Figura 6.27 apresenta a estrutura de um pedido. No cabega- 
lho aparece o numero de pedido, a data e o cliente que o realizou (codigo, 
nome e uma lista com numero variado de telefones). Apos e listado, para cada 
pega pedida, seu codigo, sua descrigao e a quantidade pedida. 

Execute a normalizacao do documento, mostrando cada uma das formas 
normais. 

Exercicio 6.17: (refere-se ao sistema de controle de almoxarifado descrito no 
Exercicio 3.10) A Figura 6.28 apresenta a estrutura da lista de busca. Para cada 
pedido e emitida uma lista de busca. O cabecalho da lista de busca contem o 
numero de pedido, sua data e o seu cliente (codigo e nome). Apos, para cada 
corredor, sao listados o receptaculo visitado, o codigo da pega a apanhar, sua 
descrigao e a quantidade a buscar. 

Exercicio 6.18: Realize a integragao dos modelos referentes aos documentos e 
arquivos do sistema de almoxarifado que voce normalizou nos exercicios pre- 
cedentes. 

Exercicio 6.19: Identifique as chaves estrangeiras no modelo resultante da 
integragao feita no exercicio anterior. 

Pedido 


Pedido: (— noPed— ) Data do pedido: (--data—) 

Codigo do Cliente: (— codClie— ) 

Nome do Cliente: (— NomeCiiente) 

Telefones pi contato: (— noTel— ) (— noTel— ) (— noTel— ) 


Codigo Descrigao Quantidade 

Pe$a Pe$a Pedido 


(...) (...) (...) 

(...) (...) (...) 


Figura 6.27: Pedido 

Exercicio 6.20: Construa um diagrama ER a partir do modelo relacional ob- 
tido no exercicio anterior. Utilize o processo de engenharia reversa descrito na 
Segao 5.3. 

Exercicio 6.21: Identifique as difcrencas do modelo ER construido no exerci- 
cio anterior com o modelo ER construido no Exercicio 3.10. Comente a causa 
das diferengas. 



Lista de Busca 


Pedido: (■ — -noPed— ) Data do pedido: (--data—) 
Codigo do Cliente: (— codClie— ) 

Nome do Cliente: (— NomeCliente) 

Corredor: (— noCorr— ) 


Numero 

Codigo 

Descrigao 

Quantidade 

Receptaculo 

Pega 

Pega 

a Buscar 

(...) 

(...) 

(...) 

(...) 

(...) 

(...) 

(...) 

(...) 

(...) 

(...) 

(...) 

(...) 

Corredor: (—noCorr—) 



Numero 

Codigo 

Descrigao 

Quantidade 

Receptaculo 

Pega 

Pega 

a Buscar 

(...) 

(...) 

(...) 

(...) 

(...) 

(...) 

(...) 

(...) 


Figura 6.28: Lista de busca 
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Capitulo 

7 

Solugoes de 
exercicios 
selecionados 


O presente capitulo tem por objetivo apresentar as solugoes de exercicios sele- 
cionados. Procurei apresentar solugoes para todos os problemas mais compli- 
cados. 

Em muitos casos, particularmente nos estudos de caso, nao ha uma 
unica solugao correta. Como as descrigSes dos sistemas sao informais, elas se 
prestam a diferentes interpretagoes. Por este motivo, em alguns estudo de 
caso mais complexos, nao e apresentada somente uma solugao, mas sao dis- 
cutidas alternativas, tanto corretas quanto incorretas. 

Exercicio 2.4. Grande parte do exercicio esta resolvida na Segao 3.1.2. La e 
apresentado um diagrama de ocorrencias que mostra que: 

□ Uma pessoa pode estar casada com ela mesma e 

□ Uma pessoa pode participar de dois casamentos, desde que na posigao de 
marido em um casamento e de esposa em outro. 

A Figura 7.1 mostra como e possivel excluir as duas possibilidades acima do 
modelo ER. A mudanga que foi feita em relagao ao modelo original (Figura 
2.4) foi a de transformar CASAMENTO em entidade e, com isso, abrir a possi- 
bilidade de especificar a cardinalidade do relacionamento de casamento com 
pessoa. 



Figura 7.1: Implementando restrigoes no casamento 


Uma outra alternativa que poderia ser considerada e a de especializar a 
entidade PESSOA em homens e mulheres. Essa solugao somente deve ser 
considerada caso existam atributos diferentes para homens e mulheres. 
Exercicio 2.5. A Figura 7.2 apresenta um possivel diagrama de ocorrencias 
para o relacionamento de SUPERVISAO. Este diagrama modela as seguintes 
instancias do relacionamento: 

□ el e supervisor de el 

□ el e supervisor de e3 

□ e3 e supervisor de e4 

□ e3 e supervisor de e5 



Figura 7.2: Diagrama de ocorrencias para o relacionamento SUPERVISAO 

Na Segao 3.1.2, e mostrado um outro exemplo de diagrama de ocorren- 
cias, contendo uma situagao, que, apesar de permitida pelo diagrama, nao 
corresponde a nossa intengao ao modelar o relacionamento de SUPERVISAO. 
Exercicio 2.7. A Figura 7.3 mostra o resultado da transformagao do modelo ER 
da Figura 2.10 em um diagrama que nao contem relacionamentos ternarios. 

Observe que uma instancia de DISTRIBUIQAO e identificada pelos tres 
relacionamentos de que participa. 

Estritamente falando, este modelo nao e equivalente ao modelo original 
com relacionamento ternario. A diferenga entre os modelos esta no fato de o 
modelo sem relacionamento ternario nao conter a restrigao que especificava 
que um produto, em uma cidade, somente pode possuir um distribuidor. Esta 
restrigao somente e representavel no modelo com relacionamentos ternarios, 
ja que somente neste e possivel falar de cardinalidade em relagao a pares de 
entidades. Entretanto, se desconsiderarmos este detalhe, ambos modelos sao 
equivalentes. 

Uma solugao que a primeira vista pode parecer equivalente ao relacio- 
namento ternario e a apresentada na Figura 7.4. Esta solu^ao nao e equiva- 
lente a original. Nela ocorre perda de informagSes. O leitor podera certificar- 


se deste fato se construir e comparar exemplos com ocorrencias para o modelo 
original e para o modelo da Figura 7.4. 



Figure 7.3: Transformagao de relacionamento ternario em entidade 



Figura 7.4: Tentativa de transformagao de relacionamento ternario 

Exercicio 2.11 A transformagao do relacionamento ATUAQAO da Figura 2.16 
em entidade resulta no modelo ER da Figura 7.5. Observe que uma ocorrencia 
de ATUAQAO e identificada pelos relacionamentos com as entidades 
PROJETO e ENGENHEIRO. 




.OAn) 




ENGENHEIRO 



ATUAQAO 


PROJETO 


i a 6 — n 

Cddigo Nome Fungao Codiqo Tftulo 


Figura 7.5: Resultado de transformagao de relacionamento em entidade 

Exercicio 2.12 A Figura 7.6 apresenta um modelo ER que resulta da modifica- 
gao do modelo da Figura 2.20. A modificagao consta em possibilitar que um 
dependente seja empregado. Caso se mantivesse o modelo original o nome do 
dependente seria armazenado redundantemente. A solugao adotada foi a de 
especializar a entidade DEPENDENTE em duas, DEP.N EMP., que contem os 


atributos dos dependentes que nao sao empregados e DEP.EMP., que nao 
contem atributos mas esta relacionada a entidade empregado correspondente. 



Figura 7.6: Dependente pode ser empregado 

Exercicio 2.16 Caso nao seja usados atributos multi-valorados e necessario 
criar uma entidade para cada atributo multi-valorado. Observar o identifica- 
dor desta entidade. Um telefone e identificado pelo seu nome e pelo cliente 
correspondente. Isso permite que diferentes clientes tenham o mesmo numero 
de telefone (o que era permitido pelo modelo original). 



O nome 


(0,n) 


TELEFONE 


1 


telefone 


Figura 7.7: Transformagao de atributo multi-valorado em entidade 

Exercicio 2.17 A solugao para modelar uma especializagao nao exclusiva e 
usar relacionamentos para ligar as entidades especializadas a entidade gene- 
rica (Figura 7.8). 



Figura 7.8: Tratando especializagao nao exclusiva atraves de relacionamen- 
tos 












Observe as cardinalidades dos relacionamentos. Pelo enunciado do pro- 
blema, uma pessoa pode possuir varios contratos de professor. 

Observe tambem que nesta modelagem cada entidade necessita de um 
identificador. Caso deseje-se usar como identificador da entidade especiali- 
zada o mesmo identificador da entidade generica (o que e possivel caso o re- 
lacionamento seja 1:1), a entidade especializada passa a ser tratada como enti- 
dade fraca. Ela e identificada pelo relacionamento com a entidade generica. 
Exercicio 2.22 Nao e possivel expressar esta restri^ao pelo fato de o modelo 
ER nao possuir uma notagao que expresse que a uniao de dois relacionamen- 
tos (no caso, o de VENDA com MEDICAMENTO e o de VENDA com 
PERFUMARIA) tern cardinalidade minima um. Esta restri^ao teria que ser es- 
pecificada fora do modelo ER. 

Exercicio 2.28 O modelo ER expressa que um processador de textos nao pode 
existir no banco de dados, sem que exista uma secretaria que o domine (car- 
dinalidade minima da entidade PROCESSADOR DE TEXTOS no relaciona- 
mento DOMINIO). Assim, cada vez que uma secretaria for excluida, e neces- 
sario verificar, para cada processador de textos por ela dominada. Caso ela 
seja a ultima a dominar determinado processador de textos, a secretaria nao 
podera ser excluida, ou, alternativamente, a exclusao da secretaria devera ser 
propagada a exclusao do processador de textos em questao. 

Exercicio 2.29 Pela defini^ao de especializagao que consideramos neste livro, a 
mesma e exclusiva, isto e, uma ocorrencia da entidade generica nao pode apa- 
recer em mais de uma de suas especializagoes. Como as entidades 
SECRETARIA, ENGENHEIRO e GERENTE sao ambas especializagSes de 
EMPREGADO na mesma hierarquia de generalizagao/especializagao, um 
empregado nao pode aparecer em mais de uma delas. 

Para permitir que uma secretaria ou um engenheiro sejam gerentes e ne- 
cessario retirar a entidade GERENTE da mesma hierarquia de generaliza- 
gao/especializagao na qual aparecem SECRETARIA e ENGENHEIRO. Neste 
caso, GERENTE passa a ser um auto-relacionamento de EMPREGADO. 
Exercicio 3.1 

a) O relacionamento apresentado nao inclui a restricao de que um produto 
nao pode ser composto por ele mesmo. 

b) A Figura 7.9 apresenta um modelo ER que exclui a possibilidade de um 
produto ser composto por ele mesmo. Cabe observar que esta solu^ao so- 
mente deve ser adotada, caso existam atributos especificos das varias es- 
pecializagoes de PRODUTO. Caso nao existam atributos especificos para 
estas especializagSes, a melhor alternativa seria manter o modelo original, 
expressando a restricao de integridade em questao fora do modelo. 

c) Caso deseje-se armazenar no banco de dados uma hierarquia com numero 
nao limitado de niveis de composigao, fica impossivel registrar no modelo 
o fato de um produto nao poder aparecer em sua composigao. Essa restri- 
gao exige o uso de recursividade em sua expressao, o que nao esta dentro 
do poder de expressao de modelos ER. 



Figura 7.9: Estrutura de produto com numero fixo de niveis 

Exercicio 3.3 No modelo, ha atributos especificos de pessoa fisica, outros es- 
pecificos de pessoa jurfdica e alguns comuns a ambos tipos de clientes. Este e 
o caso tipico para a aplicagao do conceito de generalizagao/especializagao. A 
apresenta um modelo para a mesma realidade usando este conceito. 



Figura 7.10: Substituindo atributos opcionais por especializagoes 

O novo modelo e mais preciso que o original. No original, os atributos 
das entidades especializadas apareciam como opcionais. O modelo nao in- 
formava que atributos pertenciam a qual tipo de cliente e se o atributo era ou 
nao obrigatorio para um tipo de cliente. 

No novo modelo, fica claro que atributos pertencem a cada uma das es- 
pecializagSes e se eles sao ou nao obrigatorios. 

Exercicio 3.5 Para o estudo de caso da administradora de imoveis, vamos se- 
guir os passos do processo de modelagem descrito na Segao 3.5.2. 1. 

1. Enumeragao de entidades 

Uma primeira leitura do enunciado resulta nas seguintes entidades: 

ADMINISTRADORA, CONDOMINIO, UNIDADE, PESSOA 

2. Identificagao de relacionamentos 

Os relacionamentos que podem ser identificados sao os seguintes: 


> COMPOSIQAO entre CONDOMINIO e UNIDADE 

> PROPRIEDADE entre UNIDADE e PESSOA 

> ALUGUEL entre UNIDADE e PESSOA 

Um relacionamento que poderia parecer necessario e o que liga 
ADMINISTRADORA com CONDOMINIO. Caso o BD que esteja sendo 
modelado seja destinado a uma administradora somente (como e o caso 
de exemplo), este relacionamento nao deve aparecer no modelo. Como a 
entidade ADMINISTRADORA possui uma unica instancia, nao e necessa- 
rio manter no BD a informagao de que administradora administra que 
condominio. Este relacionamento somente deveria aparecer, caso varias 
administradoras pudessem coexistir no mesmo BD (ver discussao na Se- 
gao 3.3.5) 

3. Identificagao de cardinalidades mdximas 

As cardinalidades identificadas aparecem no DER da 



Figura 7.1 1: Diagrama ER para a administradora de imoveis 

Exercicio 3.6 Seguindo os passos do processo de modelagem, chegamos aos 
seguintes resultados. 

1. Enumeragao de entidades 

LOCADORA, FUME, FITA, CLIENTE, CATEGORIA, ATOR 
Uma alternativa de modelagem seria considerar a categoria de um filme 
como atributo de FILME. Como consideramos que o conjunto de catego- 
rias de filmes nao e imutavel e pode variar ao longo da vida do BD, prefe- 
rimos modelar a categoria como uma entidade (ver discussao na 3.2.1). 
Outra decisao e a de como modelar o emprestimo, se atraves de uma en- 
tidade ou um relacionamento. Optamos por modela-lo como relaciona- 
mento. 

2. Identificagao de relacionamentos 

> entre FILME e FITA 

> EMPRESTIMO entre FITA e CLIENTE 


> entre FILME e CATEGORIA 

> ESTRELA entre ATOR e FILME 

Como no estudo de caso precedente, a entidade LOCADORA esta isolada 
por possuir uma unica instancia. 

As cardinalidades maximas sao simples de obter a partir do enunciado e 
aparecem no diagrama ER da Figura 7.12. 

3. Determinagao de atributos 

Um primeiro levantamento de atributos, com base na leitura do enunci- 
ado resulta nos atributos que aparecem no DER da Figura 7.12. O unico 
atributo que nao aparece explicitamente no enunciado e o numero do rolo 
(atributo de fita). Este atributo e necessario para filmes multi-rolo, para 
identificar que rolo do filme esta armazenado na fita. 



id titul o no me nome 

popular artfetico 


Figura 7.12: Diagrama ER para locadora de videos (primeira versao) 

4. Determinagao de identificadores 

Cada entidade do modelo deve ter seus identificadores (atributos e/ou 
relacionamentos) definidos. Alguns identificadores aparecem explicita- 
mente no enunciado do problema: 

> Cada fita e identificada por seu numero. 

> Cada filme possui um identificador. 

> Cada cliente e identificado por seu numero. 

Para as demais entidades e necessario criar um identificador. Nomes ou 
outros atributos que ocupem muito espago de armazenamento nao sao re- 
comendados, caso se tenha em visto uma implementagao em SGBD rela- 
cional, ja que eles resultam em estruturas internas de acesso pouco efici- 
entes. Por este motivo, e necessario criar atributos identificadores para as 
entidades CATEGORIA e ATOR. 

5. Verificagao de aspectos temporais 

Nao ha atributos nem relacionamentos dos quais deva ser mantida histo- 
ria. Nao ha alteragSes a fazer no que tange a aspectos temporais. 


6. Dominios dos atributos 

Nesta etapa devem ser definidos os dominios dos atributos. Isso normal- 
mente e feito ja com uso de uma ferramenta CASE. Assim, nos estudos de 
caso, deixaremos de lado esta etapa. 

7. Definigao de cardinalidades minimus 

Na Figura 7.13 estao apresentadas as cardinalidades minimas que podem 
ser deduzidas do enunciado do problema 



id 
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nome nome 
popular artistico 


Figura 7.13:Diagrama ER para locadora de video (final) 

Exercicio 3.7 

1. Enumeragdo de entidades 

A leitura do enunciado nos leva as seguintes entidades: COMPANHIA, 
RESERVA, PASSAGEIRO, TRECHO, VOO, CIDADE, AEROPORTO, 
TIPO-AERONAVE, HORARIO, ASSENTO. 

Nao foi criada uma entidade correspondente as pessoas que efetivaram a 
reserva. Nao serao armazenadas informagSes sobre estas pessoas. Deci- 
diu-se nao cadastrar pessoas de forma central, pois esta operagao deman- 
daria tempo e seriam necessarias informagSes adicionais sobre a pessoa 
para resolver o problema de homonimos. Por isso, esta informagao sera 
modelada como um atributo da reserva. 

2. Identificagao de relacionamentos 

Os relacionamentos identificados aparecem no diagrama ER da Figura 
7.14. 

O relacionamento RSRV-TRCH associa a reserva aos varios trechos de 
voo que a compoem. Ele representa cada trecho de voo reservado. 

Este relacionamento esta sendo tratado como uma entidade associativa, 
pois, para marcar o assento, e necessario relacionar cada trecho da reserva 
com o assento reservado. 



Figura 7.14: Diagrama ER para sistema de reserva de passagens aereas 

3. Determinagao de atributos e identificadores 

Para nao sobrecarregar o diagrama, listamos os atributos das entidades 
abaixo. Os atributos identificadores estao sublinhados e os relaciona- 
mentos identificadores aparecem no diagrama ER da Figura 7.14. 
RESERVA ( codiqo reserva . passageiro,prazo) 

VOO ( numera l 
TRECHO () 

AEROPORTO (codigo, nome) 

CIDADE (codigo, nome, pais) 

TIPO AERONAVE (codigo, descrigao) 

HORARIO ( dia semana , horario partida, horario chegada) 

ASSENTO (numero, ciasse) 

RSRV-TRCH ( data ) 

4. Restrigdes que nao podem ser representadas no modelo 

Neste sistema aparecem diversas restrigoes que nao se deixam representar 
em modelos ER: 

> Uma reserva de trecho somente pode ser realizada caso existam vagas 
no trecho em questao na data em questao. 

> Uma reserva para um assento somente pode ser feita, se o assento em 
questao existir no tipo de aeronave utilizada no trecho de voo em 
questao. 

Uma observagao geral sobre a solugao adotada e que ela e conceitual e 
procura apenas fixar as necessidades de informagao do sistema. O modelo 


nao inclui redundances de dados que objetivem melhorar a performance de 
determinadas operates executadas muito freqiientemente. Estas considera- 
g5es devem ficar para uma fase posterior do projeto do BD. Neste caso, atri- 
butos redundantes, como o numero de vagas em um trecho de voo, em uma 
data, inclusive discriminado por classe, poderia ser necessario. Isso levaria a 
necessidade de criagao de uma entidade TRECHO- DIA correspondendo a 
cada viagem especifica de um trecho de voo em uma data. 

Exercicio 3.8 Sistema para locadora de veiculos 

1. Enumeragao de entidades 

Uma primeira leitura do enunciado nos leva as seguintes entidades: 
LOCADORA, TIPO AUTOM OU CAMIONETA PASS, TIPO CAMIONETA 
CARGA, VEICULO, PESSOA FISICA, PESSOA JURIDICA e FILIAL 
Alem destas, sao necessarias as entidades RESERVA e LOCAQAO para 
manter informagSes sobre as duas transagSes centrais da locadora. 

Ha varios atributos e relacionamentos comuns as entidades TIPO AUTOM 
OU CAMIONETA PASS e TIPO CAMIONETA CARGA. Por este motivo, e 
usada uma generalizagao das tres entidades (TIPO VEICULO). 

Raciocinio analogo pode se aplicado as entidades PESSOA FISICA e 
PESSOA JURIDICA, levando a generalizagao CLIENTE. 

A entidade RE VI SAO e usada para manter as informagSes sobre as revi- 
s5es que devem ser feitas em veiculos do tipo. Essa informagao e multi- 
valorada (ha varias revisSes para um tipo de veiculo) e por isso nao pode 
ser armazenada em um atributo de TIPO VEICULO. 

A entidade MOTORISTA destina-se a armazenar informagSes sobre a ha- 
bilitagao do motorista que esta dirigindo o veiculo. Estas informacoes nao 
foram colocadas em CLIENTE ja que um cliente pessoa juridica pode ter 
diferentes motoristas cadastrados. 

2. Identificagao de relacionamentos 

Os relacionamentos identificados aparecem no diagrama ER da Figura 
7.15. 

Entre as entidades RESERVA e FILIAL sao usados dois relacionamentos, 
um para representar a filial onde o veiculo sera retirado (origem) e outro 
para representar a filial em que o veiculo sera devolvido (destino). 

A LOCAQAO esta opcionalmente ligada a uma filial de destino. Este rela- 
cionamento serve para informar em que filial o veiculo sera devolvido, 
caso seja devolvido em filial diferente daquela em que foi retirado. 

O relacionamento entre MOTORISTA e CLIENTE serve para informar 
quais sao os motoristas cadastrados por um cliente. 

O relacionamento entre MOTORISTA e LOCAQAO serve informar o mo- 
torista que esta responsavel pelo automovel. Observe que nao ha um rela- 
cionamento direto entre LOCAQAO e CLIENTE, ja que este seria redun- 
dante (para cada locagao, tem-se seu motorista e, para cada motorista, 
tem-se o cliente correspondente). 



Figura 7.15: Diagrama ER para sistema de locadora de vefculos 

3. Determinagdo de atributos e identificadores 

Os atributos das entidades sao os seguintes: 

CLIENTE ( codiqo . nome, enderego) 

P FISICA (sexo, data nascimento, CIC) 

P JURIDICA (CGC, inscrigao estadual) 

FILIAL ( codiqo . locaiizagao) 

VEICULO ( placas . numero chassis, numero motor, cor, quilometragem, 
data medida quilometragem, quilometragem ultima revisao) 
TIPO VEICULO ( codiqo , tipo, horas limpeza, quilometragem media diaria) 
T AUTOM CAM PASS (tamanho, numero passageiros, ar-condicionado, 
radio, toda-fitas, CD, diregao hidraulica, cambio automatico) 

T CAM CARGA (capcacidade carga) 

REVISAO ( quilometragem ) 

MOTORISTA ( numero habilitagao , data vencimento, identidade, nome) 
RESERVA ( numero , data retirada, data devolugao) 

LOCAQAO ( numero , data retirada, data devolugao) 

LOCADORA ( CGC , nome, enderego, telefone) 

Os atributos identificadores estao sublinhados na lista acima. Os relacio- 
namentos identificadores estao representados no diagrama ER da Figura 
7.15. 

4. Restrigdes que nao podem ser representadas no modelo 

As restrigoes que nao estao apresentadas no modelo acima sao: 

> A habilitagao de um motorista nao pode veneer durante o perfodo pre- 
visto para a locagao. 

> Um veiculo cuja quilometragem exceda a quilometragem de sua pro- 
xima revisao nao pode ser locado. 

> Para um cliente pessoa fisica somente deve haver um motorista cadas- 
trado. Neste caso, nao deve ser informado o nome do motorista, ja que 
ele e a propria pessoa fisica. 


> Somente pode ser feita uma reserva caso existam vetculos do tipo pre- 
vistos para estarem disponfveis na filial de origem na data da reserva. 

> Uma locagao para a qual nao tenha sido feita reserva somente pode 
ocorrer na mesma condicao acima. 

Assim como na solugao do sistema de reservas de passagens aereas 
(Exerctcio 3.7), a presente solugao e puramente conceitual, nao incluindo re- 
dundances de dados que procurem melhorar a performance de determinadas 
operates. 

Exerctcio 3.9 Sistema de preparagao de congressos da IFIP 

Uma primeira leitura do exemplo, pode nos levar a uma serie de entidades 
modelando papeis de pessoas: autor, moderador, inscrito, membro de GT, etc. 
Alem disso, um dos objetivos do sistema que aparece impltcito no resultado, e 
o de criar um cadastro central de pessoas. Isso fica claro, quando o enunciado 
exige que a pessoa nao deva aparecer varias vezes em certos relatorios ou que 
e necessario identificar os varios papeis que uma pessoa cumpriu no passado. 
Assim, fica evidente que e necessaria uma entidade PESSOA. Uma solugao 
que poderia ser tentada e a de usar o conceito de generaliza- 
gao/especializagao, na forma apresentada na Figura 7.16. 



Figura 7.16: Usando generalizagao/especializagao para modelar papeis de 
pessoas (incorreto) 

Essa solugao nao esta correta, se considerarmos a definigao de generali- 
zagao/especializagao que apresentamos na Segao 2.4. A mesma pessoa pode 
cumprir varios papeis, inclusive em um unico congresso. O conceito de gene- 
ralizagao/especializagao nao deve ser usado quando uma entidade generica 
pode aparecer mais de uma vez em suas especializagoes (ver discussao. 

Por esse motivo, optamos por modelar os papeis que as pessoas cum- 
prem atraves de relacionamentos, conforme apresentado no diagrama da 
Figura 7.17. 

Os atributos identificados sao os seguintes: 

CONGRESSO ( codiqo . nome, data realizagao, local, prazo submissao 
artigos, prazo inscrigao 
GT ( codiqo , nome) 

PESSOA ( codiqo , nome, instituigao, enderego, telefone, fax, e-mail) 

ARTIGO ( numero , tltulo, aceito/rejeitado) 

SESSAO ( codiqo , data, hora, tltulo) 


PESSOA-GT (cargo) 

AVALIAQAO (parecer, estado avaliagao) 

O atributo estado avaliagao serve para informar se uma artigo ja foi 
distribufdo a um avaliador ou se ja retornou do avaliador e recebeu parecer. 

Observe que nao ha um relacionamento CON VI DADO. Do ponto de 
vista conceitual, este relacionamento e desnecessario. As pessoas que sao con- 
vidadas a um congresso ja se encontram no modelo (sao os autores de traba- 
lhos submetidos ao congresso, os membros do CO e do CP do congresso, e 
assim por diante). Assim, este relacionamento e redundante com as informa- 
goes ja existentes e nao deve aparecer no modelo conceitual. Observe que nao 
estamos afirmando que, mais tarde, durante o projeto logico, este relaciona- 
mento nao deva ser criado, para atender requisitos de performance da aplica- 
gao. 



Figura 7.17: Diagrama ER para o sistema de preparagao de congressos 

Pelas regras de equivalencia de modelos vistas na Segao 3.1.3, e possivel 
transformar em entidades os diversos relacionamentos n:n que aparecem no 
modelo da Figura 7.17. Nessa variante de solugao, os papeis de pessoa, como 
MODERADOR, AVALIADOR, AUTOR e outros, sao transformados em entida- 
des. A Figura 7.18 apresenta, de forma parcial um esbogo de como seria o 
modelo nesta alternativa. 

Observe, que as entidades originarias dos relacionamentos n:n nao sao 
especializagSes de PESSOA, como na Figura 7.16, mas sim entidades relacio- 
nadas a entidade PESSOA. Alem disso, os identificadores das entidades que 
representam os papeis de pessoa sao diferentes do identificador de PESSOA. 
Por exemplo, uma ocorrencia de MEMBRO GT e identificada pela pessoa que 
e membro, bem como pelo GT da qual ela participa, enquanto uma ocorrencia 
de PESSOA e identificada pelo seu codigo. 



Figura 7.18: Diagrama ER para o sistema de preparagao de congressos 
(parcial - usando entidades ao inves de relacionamentos n:n) 

Uma outra particularidade do sistema em questao, e que ele contem 
uma serie de restrigSes de integridade que nao estao expressas no modelo ER. 
A seguir, listamos estas restri^Ses: 

□ Um avaliador de um artigo deve ser avaliador cadastrado no congresso. 

□ Um avaliador de um artigo nao deve ser autor deste artigo. 

□ Um artigo que tenha sido julgado deve ter pelo menos tres avaliacoes. 

□ Um inscrito deve ter sido convidado para o congresso (ver enunciado para 
verificar quern e convidado). 

□ Somente pode aparecer em uma sessao um artigo aceito. 

Exercfcio 3.10 - Sistema de almoxarifado 

A Figura 7.19 apresenta o diagrama ER para o sistema de almoxarifado. Na 
solugao apresentada modela os itens de uma ordem de compra, de um pedido 
etc. como uma entidade e nao como um relacionamento n:n (entre ordem de 
compra/pedido/... e pega). As duas solu^oes sao equivalentes. Aqui, prefe- 
rimos usar a primeira apenas para demonstrar a sua utilizagao, diferente- 
mente dos modelos das questoes anteriores onde usamos relacionamentos 


n:n. 







Figura 7.19: Diagrama ER para o sistema de almoxarifado 

Exercicio 4.1 - Em um banco de dados relational, a chave primaria de uma 
tabela e aquela chave unica que e utilizada como chave estrangeira em tabelas 
que referenciam a chave em questao. Assim, no caso do exercicio 
CodigoEmpregado e a chave primaria da tabela Empregado, ja que ela e 
usada na tabela Dependente como chave estrangeira que referencia 
Empregado. 

Exercicio 4.2 - Em organizagao de arquivos, o termo chave secundaria e usado 
para um campo ou conjunto de campos para os quais existe um indice que 
admite duplicatas. Conforme mencionado na Segao 4. 1.2.1, na abordagem re- 
lational, o conceito de chave possui a conotagao de restrigao de integridade e 
nao de caminho de acesso. Por este motivo, o termo chave secundaria nao e 
usado na abordagem relational. 

Exercicio 4.3 - Abaixo estao indicadas as chaves primarias e estrangeiras: 

Aluno ( CodiqoAluno .Nome.CodiqoCurso) 

CodigoCurso referencia Curso 

Curso( CodiqoCurso .Nome) 

Disci plinaf CodiqoDisciplina .Nome.Creditos.CodiqoDepartamento) 
CodigoDepartamento referencia Disciplina 


Curriculof CodiaoCurso.CodiqoDisciplina .Obriqatoria-Opcional) 
CodigoCurso referencia Curso 
CodigoDisciplina referencia Disciplina 

Conceito( CodiqoAluno,CodiqoDisciplina,Ano-Semestre .Conceito) 
CodigoAluno referencia Aluno 
CodigoDisciplina referencia Disciplina 

Departamento( CodigoDepartamento .Nome) 

Exercicio 4.4 

a) Uma linha e incluida na tabela Consulta. 

A tabela Consulta contem duas chaves estrangeiras, 
(CodigoConvenio,NumeroPaciente) e CRM. Quando ocorrer uma inclusao 
em Consulta, e necessario verificar se estas chaves aparecem nas respecti- 
vas tabelas (Paciente e Medico). 

b) Uma linha e excluida da tabela Paciente. 

A tabela Paciente e referenciada em outra tabela (Consulta) por uma chave 
estrangeira. Assim, ao realizar a exclusao e necessario verificar se nao mais 
existem linhas em Consulta que referenciem a linha de Paciente que esta 
sendo excluida. 

Exercicio 5.1 A alternativa 1 (Aluno ( CodAl .Nome.CodCurso.Endereco)) e pre- 
ferivel, caso considerarmos os principios nos quais estao baseadas as regras 
de tradugao de modelos ER para modelos relacionais. Os principios sao (Se- 
gao 5.2): 

O Evitar jungoes - ter os dados necessarios a uma consulta em uma linica linha 
O Diminuir o niimero de chaves primdrias 
O Evitar campos opcionais 

A alternativa 1 atende aos dois primeiros principios. O terceiro principio nao 
e considerado neste caso, ja que nenhuma das alternativas implica em criar 
campos opcionais. 

Quanto ao primeiro principio, a alternativa 1 minimiza a necessidade de jun- 
qoes. Na alternativa 2, cada vez que forem necessarios dados do aluno junto 
com dados de seu enderego sera necessario fazer uma jungao entre as duas 
tabelas. 

Quanto ao segundo principio, a alternativa 1 implica em um menor numero 
de chaves primarias, ja que implica em uma unica tabela. 

Conforme mencionado na Segao 5.1, as regras de tradugao apresentadas re- 
presentam um conjunto de heuristicas que, em geral, levam a uma base de 
dados bem projetada. Podem existir casos, em que as regras nao devem ser 
adotadas, principalmente por limitagSes do SGBD ou consi derates de per- 
formance. Assim, podem haver situagSes em que a alternativa 2 e usada, 
mesmo violando os principios acima. Abaixo consideramos uma situagao em 
que a alternativa 2 poderia ser preferivel. 

Considere-se que os dados de aluno (nome e codigo do curso) e enderego so- 
frem constantemente alteragSes de valores. Alem disso, considere-se que o 


nome e o codigo do aluno sao alterados atraves de transagoes diferentes das 
que alteram o enderego do aluno e que estas alteragoes ocorrem de forma con- 
corrente. A maioria dos SGBD relacionais nao permite que duas transagSes 
diferentes alteram a mesma linha concorrentemente. Neste caso, a alterna- 
tiva 1 implica em seqiiencicilizar as transagSes que alteram informagSes refe- 
rentes a um mesmo aluno, fazendo com que uma tenha que esperar pela ou- 
tra. Ja na alternativa 2, como os dados estao em tabelas diferentes, as transa- 
gSes podem ser executadas de forma concorrente. 

Exercfcio 5.2 O esquema relacional referente ao modelo ER da Figura 5.23 e o 
seguinte: 

Produto ( CGC, NumeroProd , NomeComercial, TipoEmbaiagem, 

Quantidade, Pregollnitario, TipoProd, Tarja, Formula, Tipo) 

CGC referenda Fabricante 
Fabricante ( CGC , Nome, Endereco) 

Venda(Data, NumeroNota , NomeCliente.CidadeCliente) 
PerfumariaVenda( CGC, NumeroProd, NumeroNota . Quantidade, Imposto) 
(CGC, NumeroProd) referenda Produto 
NumeroNota referenda Venda 
MedicamentoVendaf CGC, NumeroProd, NumeroNota , 

Quantidade, Imposto, CRM, Numero) 

(CGC, NumeroProd) referencia Produto 
NumeroNota referencia Venda 
(CRM, Numero) referencia ReceitaMedica 
ReceitaMedicaf CRM, Numero , Data) 

Comentarios: 

□ O relacionamento entre Fabricante e Produto foi implementado atraves da 
chave estrangeira CGC dentro da tabela Produto. Como o relacionamento 
e identificador, a chave estrangeira faz parte da chave primaria da tabela. 

□ A especializagao de Produto foi implementada atraves de tabela unica (ver 
segao 5. 2.4.3 para uma discussao de altemativas). Para identificar o tipo de 
produto (medicamento ou perfumaria) foi criada uma coluna (TipoProd) 
na tabela Produto. 

□ A entidade associativa (relacionamento entre Venda e Medicamento) foi 
implementada como um relacionamento n:n atraves de tabela propria. 

□ O relacionamento com Receita Medica foi implementada atraves de chave 
estrangeira dentro da tabela referente a entidade associativa. 

Exercfcio 5.3 O esquema relacional referente ao modelo ER da Figura 5.24 e o 
seguinte: 

Escritorio ( NumeroEscr , Local) 

Contrato aluguel ( NumeroEscr, NumeroContr , Data, Duragao, 
NumeroVeic, NumeroCarMotorista, EstadoCarMotorista) 

NumeroEscr referencia Escritorio 
NumeroVeic referencia Vefculo 

Ciiente ( NurneroCartMotorista, EstadoCartMotorista , Nome, Enderego, 
Telefone) 


Veiculo ( Numero , DataProximaManutengao, Placa, CodigoTipo) 
CodigoTipo referenda TipoVeiculo 
TipoVeiculo ( CodigoTipo , Nome, ArCondicionado) 

Similaridade ( CodigoTipo, CodiqoTipoSimilar ) 

Automovel ( CodigoTipo , NumeroPortas, DiregaoHidraulica, 
CambioAutomatico, Radio) 

CodigoTipo referencia TipoVeiculo 
Onibus ( CodigoTipo , NumeroPassageiros, Leito, Sanitario) 

CodigoTipo referencia TipoVeiculo 

A implementagao segue as regras apresentadas. A unica decisao tomada foi a 
de implementar a especializagao de Tipo de Veiculo atraves de uma tabela 
para cada entidade especializada (ver discussao na segao 5. 2.4.3) 

Exercicio 5.4 A Figura 7.20 apresenta o modelo ER obtido atraves da aplicagao 
das regras de engenharia reversa de modelos relacionais. 



Figura 7.20: Modelo ER obtido atraves de engenharia reversa para o Exerci- 
cio 5.4 

Os atributos de cada entidade /relacionamento estao listados abaixo 
(atributos identificadores estao sublinhados): 

Produto ( NumeroProd .DescricaoProd.PrecoProd) 

TipoProd ( CodiqoTipoProd ,DescricaoTipoProd) 


Venda ( NumeroNF .DataVenda) 

ItemVenda (QtdeltenpPregoltem) 

Registradora ( CodReq . SaldoReg) 

Empregado (CodEmp, NomeEmp, SenhaEmp) 

A aplicagao das regras e direta. No model o, apenas foram apresentadas 
as cardinalidades que puderam ser obtidas a partir do modelo ER: 

□ A cardinalidade do relacionamento Item Venda e n:n pois ele representa 
uma tabela cuja chave primaria contem multiplas chaves estrangeiras. A 
regra nao determina a cardinalidade minima. 

□ O mesmo se aplica ao relacionamento Similar. 

□ Cada ocorrencia da entidade Produto esta associada a exatamente uma 
ocorrencia de Tipo de produto. Esta cardinalidade e obtida pelo seqiiencia 
de raciocinio abaixo: 

> O relacionamento representa a chave estrangeira CodigoTipoProd da 
tabela Produto. Como no modelo relacional todos campos sao mono- 
valorados, conclui-se que cada produto pode estar associado a no ma- 
ximo um tipo de produto (cardinalidade maxima 1). 

> Alem disso, a chave estrangeira CodigoTipoProd faz parte de uma 
chave primaria. Colunas que fazem parte da chave primaria sao obri- 
gatorias. Dai conclui-se que cada produto deve estar obrigatoriamente 
associado a um tipo de produto (cardinalidade minima 1). 

□ O relacionamento entre Venda e Empregado representa uma chave es- 
trangeira dentro da tabela Venda que nao faz parte da chave primaria. A 
unica restricao de cardinalidade que pode-se derivar do modelo relacional 
e que cada venda tern a ela associado no maximo um empregado (cardi- 
nalidade maxima 1). Como o modelo relacional do exercicio e incompleto 
e nao informa que colunas sao obrigatorias e que colunas sao opcionais, 
nao e possivel determinar se uma venda obrigatoriamente esta associada a 
um empregado ou se esta opcionalmente associada. Ja na outra diregao do 
relacionamento (quantas vendas estao associadas a um empregado) nao e 
possivel derivar nenhuma informacao referente a cardinalidade a partir do 
modelo relacional fornecido. 

□ O mesmo aplica-se ao relacionamento entre Venda e Registradora. 
Exercicio 5.5 A Figura 7.21 apresenta o diagrama ER obtido por engenharia 
reversa do modelo relacional do exercicio. Os atributos das entidades e relaci- 
onamentos estao listados abaixo (atributos identificadores sublinhados): 

Pessoa ( PessID , PessNome, DataNasc, DataFalec, Sexo) 

Local ( LocID , Cidade, Pals) 

Profissao ( ProflD , ProfNome) 

Casamento ( CasamID , DataCasam) 



Figura 7.21 : Modelo ER obtido por engenharia reversa 

Exercfcio 6.1 A passagem a segunda forma normal (2FN) consta da elimina- 
gao de dependencias funcionais parciais, isto e de colunas nao-chave que depen- 
dem apenas de uma parte da chave primaria e nao da chave primaria com- 
pleta. No caso do exercfcio, as dependencias funcionais parciais sao: 

(CodigoTipoProd,NumeroProd) -> DescricaoProd 

CodigoTipoProd -> DescricaoTipoProd 

NumeroNF -> DataVenda 

NumeroNF -» CodReg 

NumeroNF -> CodEmp 

NumeroNF NomeEmp 

Observe que o identificador de um produto e a chave composta pelo c6- 
digo do tipo do produto e pelo numero do produto. 

A passagem a 2FN resulta nas seguintes tabelas: 

2FN 

ItemVenda ( NumeroNF, CodigoTipoProd, NumeroProd , 
QtdelterrpPregoltem) 

Produto ( CodigoTipoProd, NumeroProd . DescricaoProd) 

TipoProd ( CodigoTipoProd , DescricaoTipoProd ) 

Venda ( NumeroNF . DataVenda, CodReg, CodEmp, NomeEmp) 

A passagem a 3FN consta da eliminacao das dependencias funcionais 
transitivas ou indiretas, isto e de colunas nao chave que dependem de outras 
colunas nao chave. No caso do exercfcio, ha uma dependencia funcional 
transitivas na tabela Venda que e CodEmp —> NomeEmp. Devido a esta de- 
pendencia, na passagem a 3FN, e criada a tabela Empregado. O modelo rela- 
tional resultante da passagem a 3FN e o seguinte: 


3FN 

ItemVenda ( NumeroNF.CodigoTipoProd.NumeroProd , 
Qtdeltem,Pregoltem) 

Produto ( CodiqoTipoProd, NumeroProd , DescricaoProd) 

TipoProd ( CodiqoTipoProd , DescricaoTipoProd ) 

Venda ( NumeroNF . DataVenda, CodReg, CodEmp) 

Empregado ( CodEmp . NomeEmp) 

Exercicio 6.2 A tabela nao se encontra na 2FN pois contem dependencias fun- 
cionais parciais. A passagem a 2FN resulta nas seguintes tabelas: 
( CodAluno.CodTurma ) 

( CodAluno , NomeAIuno, CodLocalNascAluno,NomeLocalNascAluno) 
( CodTurma , CodDisciplina, NomeDisciplina) 

As duas ultimas tabelas nao estao na 3FN, ja que contem dependencias 
transitivas. Sua eliminacao resulta no seguinte modelo relacional: 
( CodAluno.CodTurma ) 

( CodAluno , NomeAIuno, CodLocalNascAluno) 
( CodLocalNascAluno .NomeLocalNascAluno) 

( CodTurma . CodDisciplina) 

( CodDisciplina . NomeDisciplina) 

Exercicio 6.3 A seguir apresentamos cada uma das formas normais referentes 
ao documento. A primeira apresentada e chamada de nao-normalizada (NN) 
pois nao foi verificada quanto a nenhuma das formas normais. 

NN 

( CodConqr . NomeCongr, 

( CodGT , NomeGT), 

( NumeroArt , TitArt, AssPrincArt, 

( CodAutor . NomeAutor))) 

1 FN 

( CodConqr . NomeCongr) 

( CodConqr. CodGT . NomeGT) 

( CodConqr. NumeroArt , TitArt, AssPrincArt) 

( CodConqr, NumeroArt. CodAutor . NomeAutor) 

2FN 

( CodConqr. NomeCongr) 

( CodConqr. CodGT ) 

( CodGT , NomeGT) 

( CodConqr, NumeroArt , TitArt, AssPrincArt) 

( CodConqr, NumeroArt. CodAutor ) 

( CodAutor . NomeAutor) 

3FN=2FN 

Exercicio 6.4 A seguir e apresentada cada uma das forma normais: 

NN 

Comentario: Os campos NO-DE-AUTORES, NO-DE-REVISORES e NO- 
DE-TEMAS contem informagSes redundantes, servindo 


para controlar o numero de ocorrencias dos grupos repeti- 
dos AUTOR, TEMA e REVISOR. Por este motivo, de 
acordo com a regra descrita na Segao 6. 5. 6.3, este campos 
sao eliminados ja na passagem a forma NN. 

( CodConqr, NumeroArt , NomeCongr, TitArt, 

( CodAutor , NomeAutor) 

( CodTema , NomeTema) 

(CodReyisor, NomeRevisor, StatusRevisao) 

1 FN 

( CodConqr. NumeroArt . NomeCongr, TitArt, 

( CodConqr, NumeroArt, CodAutor . NomeAutor) 

( CodConqr, NumeroArt, CodTema , NomeTema) 

( CodConqr, NumeroArt, CodRevisor , NomeRevisor, StatusRevisao) 

2FN 

( CodConqr, NumeroArt , TitArt) 

( CodConqr, NomeCongr) 

( CodConqr, NumeroArt, CodAutor ) 

( CodAutor . NomeAutor) 

( CodConqr, NumeroArt, CodTema ) 

( CodTema , NomeTema) 

( CodConqr, NumeroArt, CodRevisor , StatusRevisao) 

( CodRevisor , NomeRevisor) 

3FN=2FN 

O arquivo contem um registro para cada artigo submetido a congresso 
Lembre do exercfcio precedente, que um artigo e identificado pelo codigo do 
congresso ao qual foi submetido e pelo seu codigo. A descrigao em COBOL 
nos informa que cada registro de artigo contem: o codigo do congresso, o 
nome do congresso, o codigo do artigo, o titulo do artigo, uma lista com os 
codigos e nomes dos diversos autores, uma lista com codigo e nome dos te- 
mas de que trata o artigo e uma lista com codigo, nome e status da revisao dos 
varios especialistas que estao julgando ou julgaram o artigo. As listas sao es- 
pecificadas em COBOL na forma de clausulas OCCURS. Os campos NO-DE- 
AUTORES, NO-DE-TEMAS e NO-DE-REVISORES apenas servem para con- 
trolar as respectivas listas de campos. Portanto, nao devem ser considerados 
na normalizagao, ja que sao redundantes (ver Segao 6. 5.6. 3). O campo de sta- 
tus da revisao pode conter dois valores diferentes e informa se o artigo ja re- 
cebeu parecer do revisor ou nao. 

Execute a normalizagao do documento, mostrando cada uma das formas 
normais. 

Exercfcio 6.5 O documento e um bom exemplo das dificuldades que pode 
apresentar a normalizagao de documentos preparados para leitura por pes- 
soas e nao para processamento eletronico. 

NN 

Comentarios: 


□ Algumas sessoes de um congresso, como a de registro ("registration") ou a 
de intervalo ("break") nao possuem moderador. As sessSes tecnicas, nas 
quais sao apresentado artigos, possuem um moderador. Para simplificar, 
considerou-se que cada sessao possui um campo moderador e que este 
campo e opcional. 

□ O documento contem chaves primarias propositadamente omitidas (ver 
Segao 6. 5. 6.1). No caso foram omitidos o numero do artigo e o codigo do 
autor e o codigo do moderador. Conforme explicado naquela Segao, estes 
campos devem ser tratados como se aparecessem no documento. 

□ O documento informa o pais dos autores. Esta informagao aparece fato- 
rada para todos os autores de um artigo que sao do mesmo pais. Para sim- 
plificar tratou-se o documento como se a inform a ^ao aparecesse para cada 
autor. 


1 FN 


( CodConqr , NomeCongr, 

( Data . 

( Hora . TituloSessao, Cod Moderador, NomeModerador 
(CodArt, TituloArt, 

(CodAutor, NomeAutor, PaisAutor))))) 


Comentario: Cada artigo e apresentado uma unica vez. Essa informagao e ne- 
cessaria para determinar a chave primaria da quarta e da quinta tabelas. 
Nestas tabelas, a chave primaria da tabela nao e a concatenacao das colunas 
chave primaria das tabelas na forma NN, como foi nos exemplos ate aqui 
apresentados. Para detalhes ver segao 6.5.1. 

( CodConqr . NomeCongr) 

( CodConqr. Data ) 

( CodConqr. Data. Hora , TituloSessao, CodModerador, NomeModerador) 
( CodConqr . Data. Hora, CodArt , TituloArt) 

( CodConqr . Data, Hora, CodArt, CodAutor , NomeAutor, PaisAutor) 

2FN 

( CodConqr . NomeCongr) 

( CodConqr. Data ) 

( CodConqr. Data, Hora , TituloSessao, CodModerador, NomeModerador) 
( CodConqr, CodArt . TituloArt, Data, Hora,) 

( CodConqr, CodArt, CodAutor ) 

( CodAutor . NomeAutor, PaisAutor) 

3FN 

( CodConqr . NomeCongr) 

( CodConqr. Data ) 

( CodConqr, Data, Hora , TituloSessao, CodModerador) 

( CodModerador . NomeModerador) 

( CodConqr, CodArt , TituloArt, Data, Hora,) 

( CodConqr, CodArt, CodAutor ) 

( CodAutor . NomeAutor, PaisAutor) 


Exercicio 6.6 
NN 

Comentarios: 

□ O documento e uma carta que e enviado para o autor principal do artigo. 
Assim, o documento e identificado pelo codigo do congresso e o numero 
do artigo (identificagao de artigo). 

□ Como no exercicio anterior, ha uma chave primaria omitida, que e o iden- 
tificador do autor. 

□ O documento nao contem grupos multi-valorados de dados. Por isso, nao 
ha tabelas aninhadas 

(CodAutorPrinc, NomeAutor, InstituicaoAutor, RuaNumAutor, 

CidadeAutor, EstadoAutor, PaisAutor, NumArtiqo , TituloArtigo, 
CodConqr , NomeCongr, DataCongr, LocalCongr, DataLimCongr) 

1 FN=NN 
2FN 

( CodConqr. NumArtiqo . CodAutorPrinc, NomeAutor, InstituicaoAutor, 
RuaNumAutor, CidadeAutor, EstadoAutor, PaisAutor, TituloArtigo) 
( CodConqr . NomeCongr, DataCongr, LocalCongr, DataLimCongr) 

3FN 

( CodConqr, NumArtiqo . CodAutorPrinc, TituloArtigo) 

( CodAutorPrinc , NomeAutor, InstituicaoAutor, RuaNumAutor, 
CidadeAutor, EstadoAutor, PaisAutor) 

( CodConqr . NomeCongr, DataCongr, LocalCongr, DataLimCongr) 
Exercicio 6.7 
NN 

( CodConqr . NomeCongr, DatalnscrCongr, 

( CodGT , NomeGT), 

( Codlnscr . Nomelnscr, Paislnscr)) 

1 FN 

( CodConqr . NomeCongr, DatalnscrCongr) 

( CodConqr, CodGT , NomeGT) 

( CodConqr, Codlnscr . Nomelnscr, Paislnscr) 

2FN 

( CodConqr . NomeCongr, DatalnscrCongr) 

( CodConqr, CodGT ) 

( CodGT . NomeGT) 

( CodConqr, Codlnscr ) 

( Codlnscr , Nomelnscr, Paislnscr) 

3FN=2FN 
Exercicio 6.8 

Os modelos normalizados de cada documento estao listados abaixo. Adicio- 
nalmente, cada tabela recebeu um nome. Isto facilita identificar tabelas que 
devam ser juntadas. 

Modelo do Exercicio 6.3 


Congresso ( CodCongr, NomeConqr) 

CongrGT ( CodCongr, CodGT ) 

GT ( CodGT . NomeGT) 

Artigo ( CodCongr, NumeroArt , TitArt, AssPrincArt) 

ArtigoAutor ( CodCongr. NumeroArt, CodAutor ) 

Autor ( CodAutor , NomeAutor) 

Modelo do Exercicio 6.4 

Artigo ( CodCongr, NumeroArt . TitArt) 

Congresso ( CodCongr, NomeConqr) 

ArtigoAutor ( CodCongr, NumeroArt, CodAutor ) 

Autor ( CodAutor , NomeAutor) 

CongrTema ( CodCongr, NumeroArt, CodTema ) 

Tema ( CodTema , NomeTema) 

CongrRevisao ( CodCongr, NumeroArt, CodRevisor , StatusRevisao) 
Revisor ( CodRevisor , NomeRevisor) 

Modelo do O arquivo contem um registro para cada artigo submetido a 
congresso Lembre do exercicio precedente, que um artigo e identificado pelo 
codigo do congresso ao qual foi submetido e pelo seu codigo. A descrigao em 
COBOL nos informa que cada registro de artigo contem: o codigo do 
congresso, o nome do congresso, o codigo do artigo, o titulo do artigo, uma 
lista com os codigos e nomes dos diversos autores, uma lista com codigo e 
nome dos temas de que trata o artigo e uma lista com codigo, nome e status 
da revisao dos varios especialistas que estao julgando ou julgaram o artigo. 

As listas sao especificadas em COBOL na forma de clausulas OCCURS. Os 
campos NO-DE-AUTORES, NO-DE-TEMAS e NO-DE-REVISORES apenas 
servem para controlar as respectivas listas de campos. Portanto, nao devem 
ser considerados na normalizagao, ja que sao redundantes (ver Segao 6.5. 6.3). 
O campo de status da revisao pode confer dois valores diferentes e informa se 
o artigo ja recebeu parecer do revisor ou nao. 

Execute a normalizagao do documento, mostrando cada uma das formas 
normais. 

Exercicio 6.5 

Congresso ( CodCongr , NomeCongr) 

CongrData ( CodCongr, Data ) 

Sessao ( CodCongr, Data, Hora , TituioSessao, Cod Mode rador) 
Moderador ( CodModerador , NomeModerador) 

Artigo ( CodCongr, CodArt , TituioArt, Data, Hora,) 

ArtigoAutor ( CodCongr, CodArt, CodAutor ) 

Autor ( CodAutor , NomeAutor, PaisAutor) 

Modelo do Exercicio 6.6 

Artigo ( CodCongr, NumArtioo , CodAutorPrinc, TituloArtigo) 

Autor ( CodAutorPrinc , NomeAutor, InstituicaoAutor, RuaNumAutor, 
CidadeAutor, EstadoAutor, PaisAutor) 

Congresso ( CodCongr , NomeCongr, DataCongr, LocaiCongr, 
DataLimCongr) 


Modelo do Exercicio 6.7 

Congresso ( CodConqr , NomeCongr, DatalnscrCongr) 

CongrGT ( CodConqr, CodGT ) 

GT ( CodGT . NomeGT) 

Congrlscr ( CodConqr. Codlnscr ) 

Inscrito ( Codlnscr . Nomelnscr, Paislnscr) 

Modelo integrado 

Artigo ( CodConqr, NumeroArtiqo TituloArt, AssPrincArt, CodAutorPrinc, 
Data, Hora) 

ArtigoAutor ( CodConqr. NumeroArt, CodAutor ) 

Pessoa ( CodPess , NomePess, Instituicao, RuaNum, Cidade, Estado, 
Pais) 

Congresso ( CodConqr . NomeCongr, DataCongr, LocaiCongr, 
DataLimCongr, DatalnscrCongr) 

CongrGT ( CodConqr, CodGT ) 

Congrlscr ( CodConqr. Codlnscr ) 

ArtRevisao ( CodConqr, NumeroArt. CodRevisor , StatusRevisao) 
ArtTema ( CodConqr. NumeroArt, CodTema ) 

GT ( CodGT . NomeGT) 

Sessao ( CodConqr. Data, Hora , TituloSessao, Cod Mode rador) 

Tema ( CodTema , NomeTema) 

Comentarios: 

□ Nos diferentes modelos, a mesma tabela aparece sob diferentes nomes (o 
problema dos sinonimos descrito na Segao 6.6). Trata-se de uma unica ta- 
bela, que deve constar uma unica vez no modelo integrado. Por exemplo, 
as varias tabelas que contem dados de pessoas (autor, moderador, revisor, 
...) foram unidas na tabela Pessoa. O mesmo problema de sinonimos 
aplica-se a campos. O campo numero do artigo aparece uma vez sob a de- 
nominagao CodArtigo e outra sob a denomina^ao NumArtigo. 

□ A tabela CongrData foi eliminada pelo fato de seus dados estarem conti- 
dos dentro da tabela Sessao. Para detalhes ver Segao 6.6.2. 

Exercicio 6.9 

Artigo ( CodConqr, NumeroArtiqo TituloArt, AssPrincArt, CodAutorPrinc, 
Data, Hora) 

CodCongr referenda Congresso 
(CodCongr, Data, Hora) referenda Sessao 
CodAutorPrinc referenda Pessoa 
ArtigoAutor ( CodConqr. NumeroArt, CodAutor ) 

(CodCongr, NumeroArt) referenda Artigo 
CodAutor referenda Pessoa 

Pessoa ( CodPess . NomePess, Instituicao, RuaNum, Cidade, Estado, 
Pais) 

Congresso ( CodConqr . NomeCongr, DataCongr, LocaiCongr, 
DataLimCongr, DatalnscrCongr) 

CongrGT ( CodConqr. CodGT ) 


CodCongr referenda Congresso 
CodGT referencia GT 
Congrlscr ( CodCongr, Codlnscr ) 

CodCongr referencia Congresso 
Codlnscr referencia Pessoa 

ArtRevisao ( CodCongr, NumeroArt, CodRevisor, StatusRevisao) 
(CodCongr, NumeroArt) referencia Artigo 
CodRevisor referencia Pessoa 
ArtTema ( CodCongr. NumeroArt, CodTema ) 

(CodCongr, NumeroArt) referencia Artigo 
CodTema referencia Tema 
GT ( CodGT . NomeGT) 

Sessao ( CodCongr. Data, Hora , TituloSessao, Cod Mode rador) 

CodCongr referencia Congresso 
CodModerador referencia Pessoa 
Tema ( CodTema , NomeTema) 

ObservagSes: 

□ As varias colunas que compoem uma chave estrangeira nao aparecem 
necessariamente juntas na tabela. Este e o caso da chave estrangeira 
CodCongr, Data, Hora que aparece na tabela Artigo e que referencia a 
tabela Sessao. 

□ A chave estrangeira nao necessariamente tem o mesmo nome da chave 
primaria que referencia. Este e o caso das varias chaves estrangeira que re- 
ferenciam a tabela Pessoa no exemplo. 

Exercfcio 6.10 e Exercfcio 6.11 

A Figura 7.22 apresenta do diagrama ER obtido atraves da engenharia 
reversa do modelo relacional obtido no exercfcio precedente. 

Os atributos das entidades e relacionamentos do diagrama ER sao os se- 
guintes: 

Artigo ( NumeroArtigo TituloArt, AssPrincArt) 

Pessoa ( CodPess , NomePess, Instituicao, RuaNum, Cidade, Estado, 
Pais) 

Congresso ( CodCongr . NomeCongr, DataCongr, LocalCongr, 
DataLimCongr, DatalnscrCongr) 

GT ( CodGT . NomeGT) 

Sessao ( Data, Hora , TituloSessao) 

Tema ( CodTema , NomeTema) 


ODERADOR 



Figura 7.22: Diagrama ER obtido atraves de engenharia reversa 

Em linhas gerais, os simbolos do diagrama ER tern a mesma disposigao 
que aquela apresentada no modelo do sistema de preparagao de congressos 
que aparece na Figura 7.17. Com isso e possivel comparar o diagrama obtido 
atraves da engenharia reversa com aquele obtido atraves da modelagem a 
partir da descrigao do problema. 

O modelo obtido por engenharia reversa e diferente daquele obtido pela 
modelagem a partir da descrigao do problema (Figura 7.17). Varios elementos 
do modelo que haviam sido identificados na Figura 7.17 nao aparecem no 
modelo, como os relacionamentos referentes aos membros do GT, aos mem- 
bros dos comites de programa e organizador. A engenharia reversa somente 
identifica os elementos do modelo ER que aparecem nos documentos ou ar- 
quivos tratados. 

Por outro lado, da engenharia reversa resultaram alguns elementos 
(como a entidade TEMA) que nao apareciam no modelo da Figura 7.17, ja que 
eles nao haviam sido referenciados na descri^ao do problema, mas aparecem 
nos arquivos e documentos processados na engenharia reversa. 

O modelo obtido pela engenharia reversa nao e necessariamente um 
modelo perfeito. Ele pode ainda conter anomalias e ate mesmo redundances 
de dados, conforme descrito abaixo. 

A engenharia reversa nao detecta relacionamentos redundantes (ver Se- 
gao 3.3.3). Este e o caso do relacionamento entre a entidade SESSAO e a enti- 
dade CONGRESSO. O relacionamento e redundante, ja que as informagSes 
nele contidas podem ser obtidas atraves dos relacionamentos entre SESSAO e 
ARTIGO e entre ARTIGO e CONGRESSO. Este relacionamento aparece no 
modelo, pelo fato de o codigo de congresso fazer parte da chave primaria da 
entidade SESSAO. 

Outra anomalia do modelo obtido pela engenharia reversa sao os relaci- 
onamentos entre um artigo e a pessoa que e autora do artigo. Foram identifi- 
cados dois relacionamentos, um que informa o autor principal de cada artigo 
e outro que informa o conjunto de todos autores do artigo. Do ponto de vista 


de modelagem conceitual, estes relacionamentos nao estao incorretos. Entre- 
tanto, do ponto de vista do desenvolvimento de aplicagSes sobre o banco de 
dados em questao, a separagao dos autores de um artigo em dois conjuntos 
complica o tratamento (alteragSes e consul tas) de autores, ja que exige um 
tratamento especial para o autor principal do artigo. O tratamento de autores 
e mais simples se for utilizado um unico relacionamento de autoria, tendo 
este relacionamento um atributo que informa se o autor e ou nao o autor prin- 
cipal do artigo. 

Alem dos problemas acima mencionados, o modelo demonstra o resul- 
tado de um documento conter uma chave primaria implicita e de ela nao ter 
sido tratada durante a normalizagao (ver Segao 6. 5. 6.1). Na entidade ARTIGO 
aparece uma coluna denominada AssPrincArt. Esta coluna contem a descrigao 
do assunto ou tema principal do artigo. Esta informagao nao deveria aparecer 
aqui na forma de um atributo de artigo e sim de um relacionamento entre as 
entidades ARTIGO e TEMA. O problema ocorreu pelo fato de nao termos de- 
tectado, quando da normalizagao do documento referente ao Exercicio 6.3 o 
fato de que todo assunto ou tema possuir um codigo. Deveriamos ter inclu- 
ido, ja na normalizagao daquele documento o codigo do tema. Fica como 
exercicio para o leitor, a revisao do resultado dos exercicios incorporando esta 
corregao. 

Exercicio 6.12 

NN 

(NoCorr, 

( NoRecept . CodPeca, DescrPeca, QtdeEstoq)) 

Observagao: O campo data de emissao do documento foi desconsiderado (ver 
Segao 6. 5. 6. 3). 

1 FN 

( NoCorr ) 

( NoCorr , NoRecept . CodPeca, DescrPeca, QtdeEstoq) 

2FN = 1 FN 
3FN 

( NoCorr ) 

( NoCorr , NoRecept . CodPeca, QtdeEstoq) 

( CodPeca , DescrPeca) 

Exercicio 6.13 

NN 

( CodOC, DataEntreqa , NoEstrado, CodOperEmpiih 

( NoCorr . 

( NoRecept . CodPeca, 

DescrPeca, QtdePeca))) 

Observagao: Os campos NO-DE-CORREDORES e NO-DE-RECEPTACULOS 
foram desconsiderados por serem redundantes, servindo apenas para con- 
trolar o tamanho dos itens de grupo do COBOL (ver Segao 6. 5.6. 3). 


1 FN 


( CodOC, DataEntrega , NoEstrado, CodOperEmpilh) 

( CodOC, DataEntrega, NoCorr ) 

( CodOC, DataEntrega, NoCorr, NoRecept , CodPeca, DescrPeca, 

QtdePeca) 

2FN = 1 FN 
3FN 

( CodOC, DataEntrega , NoEstrado, CodOperEmpilh) 

( CodOC, DataEntrega, NoCorr ) 

( CodOC, DataEntrega, NoCorr, NoRecept . CodPeca, QtdePeca) 
( CodPeca , DescrPeca) 

Exercicio 6.14 
NN 

( NoPed , CodCIi, NomeCIi, NoRampa) 

1 FN=NN 
2FN=1 FN 
3FN 

( NoPed , CodCIi, NoRampa) 

( CodCIi . NomeCIi) 

Exercicio 6.15 
NN 

( NoOC , DataOC, CodFornec, NomeFornec, 

( CodPeca , DescrPeca, QuantPed, 

( DataEntr , QuantEntr))) 

1 FN 

( NoOC , DataOC, CodFornec, NomeFornec) 

( NoOC , CodPeca , DescrPeca, QuantPed) 

( NoOC , CodPeca, DataEntr , QuantEntr) 

2FN 

( NoOC , DataOC, CodFornec, NomeFornec) 

( NoOC , CodPeca , QuantPed) 

( CodPeca , DescrPeca) 

( NoOC , CodPeca, DataEntr , QuantEntr) 

3FN 

( NoOC , DataOC, CodFornec) 

( CodFornec , NomeFornec) 

( NoOC , CodPeca , QuantPed) 

( CodPeca , DescrPeca) 

( NoOC , CodPeca, DataEntr , QuantEntr) 


Exercicio 6.16 


NN 

( NoPed , DataPed, CodCIi, NomeCIi, 

( NoTel ). 

( CodPeca , DescrPeca, QuantPed)) 

1 FN 

( NoPed , DataPed, CodCIi, NomeCIi) 

( NoPed, NoTel ) 

( NoPed, CodPeca , DescrPeca, QuantPed) 

2FN 

( NoPed , DataPed, CodCIi, NomeCIi) 

( NoPed, NoTel ) 

( NoPed, CodPeca . QuantPed) 

( CodPeca . DescrPeca) 

3FN 

( NoPed , DataPed, CodCIi) 

( CodCIi , NomeCIi) 

( NoPed, NoTel ) 

( NoPed, CodPeca . QuantPed) 

( CodPeca . DescrPeca) 

Este exercfcio exemplifica o problema referido na Segao 6.5.1, quanto a 
opgao de usar a decomposigao de tabelas na passagem a 1FN. No caso do 
exemplo, os numeros de telefone que aparecem no exemplo, sao os numeros 
dos telefones do cliente. Entretanto, ao decompor a tabela NN, o telefone fica 
desvinculado do cliente correspondente, na tabela: 

( NoPed, NoTel ) 

Quando o esquema relacional for transformado em um modelo ER, esta 
tabela correspondera a uma entidade Telefone vinculada a entidade Pedido e 
nao a entidade Cliente, como seria o correto. Deixamos a corregao deste pro- 
blema para apos a constru^ao do modelo ER. 

Exercfcio 6.17 

NN 

( NoPed , DataPed, CodCIi, NomeCIi, 

(NoCorr, 

( NoRecept , CodPeca, DescrPeca, QuantBusca))) 

1 FN 

( NoPed , DataPed, CodCIi, NomeCIi) 

( NoPed, NoCorr ) 

( NoPed, NoCorr, NoRecept . CodPeca, DescrPeca, QuantBusca) 


2FN = 1FN 
3FN 

( NoPed , DataPed, CodCIi) 

( CodCIi , NomeCIi) 

( NoPed, NoCorr ) 

( NoPed, NoCorr, NoRecept , CodPeca, QuantBusca) 

( CodPeca , DescrPeca) 

Exercfcio 6.18 

Os modelos normalizados de cada documento estao listados abaixo. Adicio- 
nalmente, cada tabela recebeu um nome. Isto facilita identificar tabelas que 
devam ser juntadas. 

Modelo do Exercfcio 6.12 
Corredor ( NoCorr ) 

Receptaculo ( NoCorr , NoRecept . CodPeca, QtdeEstoq) 

Peca ( CodPeca . DescrPeca) 

Modelo do Exercfcio 6.13 

Entrega ( CodOC, DataEntrega , NoEstrado, CodOperEmpilh) 

DistrCorr ( CodOC, DataEntrega, NoCorr ) 

ItemDistr ( CodOC, DataEntrega, NoCorr, NoRecept . 

CodPeca, QtdePeca) 

Peca ( CodPeca , DescrPeca) 

Modelo do Exercfcio 6.14 

Pedido ( NoPed , CodCIi, NoRampa) 

Cliente ( CodCIi , NomeCIi) 

Modelo do Exercfcio 6.15 

OC ( NoOC , DataOC, CodFornec) 

Fornec ( CodFornec , NomeFornec) 
ltemOC( NoOC , CodPeca , QuantPed) 

Peca( CodPeca , DescrPeca) 

ItemEntr ( NoOC , CodPeca, DataEntr , QuantEntr) 

Modelo do Exercfcio 6.16 

Pedido ( NoPed , DataPed, CodCIi) 

Cliente ( CodCIi , NomeCIi) 

Telefone ( NoPed, NoTel ) 

ItemPedido ( NoPed, CodPeca , QuantPed) 

Peca ( CodPeca , DescrPeca) 

Modelo do Exercfcio 6.17 

Pedido ( NoPed , DataPed, CodCIi) 

Cliente ( CodCIi , NomeCIi) 

BuscaCorredor ( NoPed, NoCorr ) 

ItemBusca ( NoPed, NoCorr, NoRecept . CodPeca, QuantBusca) 

Peca ( CodPeca , DescrPeca) 

Modelo integrado 


Corredor (NoCorr) 

Receptaculo ( NoCorr , NoRecept , CodPeca, QtdeEstoq) 

Peca ( CodPeca , DescrPeca) 

Entrega ( NoOC, DataEntreqa , NoEstrado, CodOperEmpilh) 

DistrCorr ( NoOC, DataEntreqa, NoCorr ) 
ltemDistr( NoOC, DataEntreqa, NoCorr, NoRecept . 

CodPeca, QtdePeca) 

Pedido ( NoPed , CodCIi, NoRampa, DataPed) 

Cliente ( CodCIi , NomeCIi) 

OC ( NoOC , DataOC, CodFornec) 

Fornec ( CodFornec , NomeFornec) 
ltemOC( NoOC , CodPeca , QuantPed) 

ItemEntr ( NoOC , CodPeca, DataEntr , QuantEntr) 

Telefone ( NoPed, NoTel ) 

ItemPedido ( NoPed, CodPeca , QuantPed) 

BuscaCorredor ( NoPed, NoCorr ) 

ItemBusca ( NoPed, NoCorr, NoRecept , CodPeca, QuantBusca) 

ObservagSes: 

□ Quando da transcrigao dos esquemas das tabelas ao modelo integrado, foi 
feito o tratamento de sinonimos (ver Segao 6.6). A coluna referente ao co- 
digo da ordem de compra, aparecia sob os nomes NoOC e CodOC. 

O Foi feito o tratamento de tabelas com chaves contidas (ver Segao 6.6.2). A 
tabela DistrCorr - (modelo do Exercicio 6.13) foi eliminada por estar con- 
tida dentro da tabela ItemDistr do mesmo exercicio. Pela mesma razao, foi 
eliminada a tabela BuscaCorredor (modelo do Exercicio 6.17). Deve ser 
observado que a tabela Corredor (modelo do Exercicio 6.12) nao foi inte- 
grada a tabela Receptaculo do mesmo modelo. Ocorre que podem haver 
estados do banco de dados, nos quais um corredor ja foi incluido na tabela 
de Corredor, mas nao aparece ainda na tabela Receptaculo (estamos con- 
siderando que corredores e receptaculos sao incluidos no banco de dados 
em transacoes diferentes). Este e o mesmo caso do terceiro exemplo da Se- 
gao 6.6.2. 

Exercicio 6.19 

Corredor ( NoCorr ) 

Receptaculo ( NoCorr , NoRecept . CodPeca, QtdeEstoq) 

NoCorr referenda Corredor 
CodPeca referenda Peca 
Peca ( CodPeca , DescrPeca) 


Entrega ( NoOC, DataEntrega , NoEstrado, CodOperEmpilh) 

NoOC referenda OC 

ItemDistrf NoOC, DataEntrega, NoCorr, NoRecept , 

CodPeca, QtdePeca) 

(NoOC, DataEntrega, CodPeca) referencia ItemEntr 
(NoCorr, NoRecept) referencia Receptaculo 

Observagao: NoOC nao foi considerado como chave estrangeira da tabela OC, 
nem (NoOC, DataEntrega) foi considerado chave estrangeira da tabela Entr. 
Estas chaves estrangeiras seriam redundantes com as demais chaves estran- 
geiras que aparecem no modelo. Fica como exercicio para o leitor, identificar 
as chaves estrangeiras com as quais estas seria redundantes. 

Pedido (NoPed, CodCii, NoRampa, DataPed) 

CodCIi referencia Cliente 
Cliente ( CodCii . NomeCIi) 

OC ( NoOC . DataOC, CodFornec) 

CodFornec referencia Fornec 
Fornec ( CodFornec . NomeFornec) 

ItemOC ( NoOC, CodPeca , QuantPed) 

NoOC referencia OC 
CodPeca referencia Peca 
ItemEntr ( NoOC, CodPeca, DataEntr . QuantEntr) 

(NoOC, DataEntr) referencia Entrega 
(NoOC, CodPeca referencia ItemOC 
Telefone ( NoPed, NoTel ) 

NoPed referencia Pedido 
ItemPedido ( NoPed, CodPeca . QuantPed) 

NoPed referencia Pedido 
CodPeca referencia Peca 

ItemBusca ( NoPed, NoCorr, NoRecept . CodPeca, QuantBusca) 

(NoPed, CodPeca) referencia Peca 
(NoCorr, NoRecept) referencia Receptaculo 
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